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Avant-propos 



« Toute la methode reside dans la mise en ordre et la disposition 
des objets vers lesquels ilfaut tourner le regard de V esprit. » (Descartes) 



Le refactoring est une activite d'ingenierie logicielle consistant a modifier le code source 
d'une application de maniere a ameliorer sa qualite sans alterer son comportement vis-a- 
vis des utilisateurs. L'objectif du refactoring est de reduire les cofits de maintenance et de 
perenniser les investissements tout au long du cycle de vie du logiciel en se concentrant 
sur la maintenabilite et l'evolutivite. 

Mises au point tres tot sur des langages orientes objet comme Smalltalk ou C++, les tech- 
niques de refactoring reposent essentiellement sur les meilleures pratiques de developpe- 
ment objet et sont done generalisables a tous les langages reposant sur ce paradigme. 

Dans le domaine Java/J2EE, le refactoring a beneficie d'outils de plus en plus sophistiques 
facilitant sa mise en oeuvre au sein des projets. Ces avancees concordent avec le tres fort 
developpement de Java/J2EE et 1' augmentation concomitante du code a maintenir. 

Objectifs de cet ouvrage 

Les objectifs de cet ouvrage sont de fournir une synthese de l'etat de l'art en matiere de 
refactoring et de dormer les elements cles permettant de l'anticiper et de le mettre en oeuvre 
dans les projets informatiques. 

Ann d'etre au plus pres de la realite du terrain, nous proposons une etude de cas detaillee 
sous la forme d'une application J2EE Open Source permettant d'etudier les problemes 
classiques rencontres sur les projets de refactoring. 
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Grace a cet ouvrage, le lecteur aura une vision globale des tenants et aboutissants du 
refactoring et disposera d'une boite a outils directement opera tionnelle, entierement 
fondee sur des produits Open Source. 

Organisation de I'ouvrage 

Cet ouvrage est divise en trois parties plus un chapitre d' introduction. II part des concepts 
sous-jacents au refactoring et s'acheve par a une etude de cas complete. 

Le chapitre 1 introduit les concepts d' evolution logicielle et de refactoring et montre en 
quoi le refactoring est une etape cle dans le cycle de vie d'une application, notamment 
dans le cadre des methodes agiles telles que l'XP (eXtreme Programming). 

La premiere partie detaille le processus de refactoring au travers de quatre chapitres, 
correspondant aux quatre etapes fondamentales du refactoring : la mise en place de 1' infra- 
structure de gestion des changements, 1' analyse du logiciel, les techniques de refactoring 
et la validation du refactoring a l'aide de tests unitaires. 

La partie II fournit en trois chapitres une synthese des techniques avancees de refactoring 
reposant sur les design patterns, la programmation orientee aspect (POA) et 1' optimisation 
des acces aux donnees. 

La partie HI est entierement consacree a 1' etude de cas. Elle presente de maniere concrete la 
mise en oeuvre du refactoring dans une application J2EE Open Source reelle. Le chapitre 9 
presente 1' architecture de 1' application et decrit 1' infrastructure a mettre en place pour 
effectuer le refactoring. Le chapitre 10 consiste en une analyse quantitative et qualitative 
complete du logiciel pour determiner le perimetre du refactoring. Le chapitre 1 1 met en 
oeuvre les principales techniques abordees dans I'ouvrage pour ameliorer la qualite de 
1' application. L utilisation de ces techniques est accompagnee des tests necessaires pour 
assurer la non-regression du logiciel. 

A propos des exemples 

Les exemples fournis dans cet ouvrage sont majoritairement comprehensibles par les 
lecteurs maitrisant les mecanismes de base du langage Java et ses principales API. 

La mise en oeuvre de ces exemples necessite 1' installation de plusieurs des outils presentes 
dans I'ouvrage. La procedure a suivre pour chaque outil est decrite en annexe. 

Nous avons deliberement choisi d'utiliser Eclipse pour nos exemples et notre etude de cas. 
Cet environnement de developpement Open Source dispose d'outils de refactoring tenant 
la comparaison avec les meilleurs produits commerciaux. Bien entendu, les techniques 
presentees dans cet ouvrage sont valables dans d'autres environnements de developpement, 
comme JBuilder ou Netbeans. 

Pour des raisons de place, seul l'essentiel du code source des exemples est reproduit. 
Le code source complet est disponible sur la page Web dediee a I'ouvrage sur le site Web 
d'Eyrolles, a l'adresse www.editions-eyrolles.com. 
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L' etude de cas est pour sa part accessible via le gestionnaire de configuration CVS du site 
communautaire Open Source SourceForge.net. La procedure a suivre est decrite en detail 
au chapitre 9. Les differentes versions du logiciel produites dans le cadre de 1' etude de cas 
sont aussi telechargeables depuis la page Web dediee a l'ouvrage du site Web d'Eyrolles. 

A qui s'adresse l'ouvrage ? 

Cet ouvrage est un manuel d'initiation au refactoring des applications Java/J2EE. II s'adresse 
done a un large public d'informaticiens, notamment les suivants : 

• Chefs de projet desireux d'apprehender le processus de refactoring afin de le mettre en 
oeuvre ou de l'anticiper sur leurs projets. 

• Developpeurs, pour lesquels la maitrise du refactoring est un atout professionnel non 
neglige able. 

• Etudiants en informatique (deuxieme et troisieme cycles universitaires, ecoles 
d'ingenieur). 

Redigee de maniere a etre lisible par ces differents publics, la majorite des chapitres de 
l'ouvrage ne necessite que la connaissance des concepts de base de la programmation 
orientee objet et du langage Java. 



1 



L'evolution logicielle 
et le refactoring 



Dans la plupart des ouvrages informatiques, nous adoptons le point de vue du createur de 
logiciel. Ainsi, les livres consacres a la gestion de projet informatique decrivent les 
processus permettant de creer un logiciel de A a Z et s'achevent generalement a la recette 
de la premiere version de celui-ci. 

Malheureusement, la creation ne represente souvent qu'une petite partie du cycle de vie 
d'un logiciel. Par exemple, dans le domaine des assurances, des logiciels sont ages de 
plusieurs dizaines d'annees et continuent d'evoluer au gre des nouvelles reglementations 
et des nouveaux produits. 

L'objectif de ce chapitre d' introduction est de proposer une synthese de revolution logicielle 
et de montrer l'importance du processus de refactoring pour faire face aux challenges 
imposes par les forces du changement. 

Le chapitre comporte trois grandes sections : 

• La premiere expose la problematique de revolution logicielle et insiste sur les moyens 
de lutter contre ses effets pervers. Le processus de maintenance qui est au coeur de cette 
problematique est decrit ainsi que le positionnement du refactoring par rapport a cette 
activite majeure de l'ingenierie logicielle. 

• La deuxieme section donne la definition du refactoring et resume les objectifs et la 
typologie des actions de refactoring. Les benefices et les challenges de cette activite 
sont en outre analyses. 

• La derniere section positionne le refactoring par rapport aux methodes agiles, le refac- 
toring se revelant une activite cle au sein de ces methodes iteratives. Bien entendu, le 
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refactoring ne se limite pas aux methodes agiles et peut etre mis en oeuvre dans le cadre 
de demarches classiques de developpement. 

La problematique de revolution logicielle 

En 1968, le phenomene de crise logicielle est identifie lors d'une conference organisee 
par l'OTAN. Par crise logicielle, nous entendons la difficulte pour les projets informatiques 
de respecter les delais, les coiits et les besoins des utilisateurs. 

Face a cette crise, de nombreuses solutions sont proposees : langages de plus haut niveau 
pour gagner en productivite, methodes de conception permettant d'ameliorer 1' adequation 
entre les fonctionnalites du logiciel et 1' expression des besoins des utilisateurs, methodes 
de gestion de projets plus adaptees, etc. 

Force est de constater que si la situation s'est amelioree depuis, elle reste encore perfectible. 
D'apres le rapport CHAOS: a Recipe for Success, du Standish Group, le taux de reussite 
d'un projet au sein d'une grande entreprise est de 29 % en 2004. Une majorite de projets 
(53 %) aboutissent, mais sans respecter le planning, le budget ou le perimetre fonctionnel 
prevus. Les 18 % restants sont constitues des projets purement et simplement arretes. 

Cette etude ne s'interesse qu'a la premiere version d'un logiciel. Or celui-ci va necessai- 
rement devoir changer pour s'adapter au contexte mouvant de ses utilisateurs. 

De notre point de vue, le succes d'un projet ne se mesure pas tant a sa capacite a delivrer 
une premiere version operationnelle du logiciel, mais a sa capacite a creer un logiciel 
assez robuste pour affronter les epreuves des forces du changement. 

En un mot, revolution logicielle est darwinienne. Ce sont les logiciels les mieux adaptes 
qui survivent. 

Le cycle de vie d'un logiciel 

La vie d'un logiciel, qu'il soit realise a facon au sein d'une entreprise ou a une fin industrielle 
chez un editeur, ne s'arrete pas apres la livraison de la premiere version. 

A l'instar des etres vivants, le cycle de vie d'un logiciel connait cinq grandes phases : 

• Naissance. Le logiciel est concu et developpe a partir de l'expression de besoins des 
utilisateurs. 

• Croissance. De nombreuses fonctionnalites sont ajoutees a chaque nouvelle version 
en parallele des correctifs. 

• Maturite. Le nombre de nouvelles fonctionnalites diminue. Les nouvelles versions 
sont essentiellement des adaptations et des corrections. 

• Declin. L ajout de nouvelles fonctionnalites est problematique, et les couts de maintenance 
deviennent redhibitoires. Le remplacement du logiciel est envisage. 
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• Mort. La decision de remplacement est prise. II peut y avoir une periode transitoire, 
pendant laquelle l'ancien logiciel et le nouveau fonctionnent en meme temps. Genera- 
lement, on assiste a une migration de la connaissance de l'ancien vers le nouveau logiciel. 
Cette connaissance est constituee, entre autres, des processus fonctionnels, des regies 
de gestion et des donnees. Cet aspect est problematique lorsque la connaissance est 
enfouie dans l'ancien logiciel et n'est pas documentee. 

Le cycle de vie elementaire d'un logiciel consiste ainsi en une succession de versions, 
chacune apportant son lot de modifications. Entre deux versions, des correctifs et des 
evolutions mineures sont realises en fonction des anomalies non detectees en recette mais 
constatees en production. 

La figure 1.1 illustre ce cycle de vie. 
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Figure 1.1 

Le cycle de vie elementaire d'un logiciel 



Le cycle de vie reel d'un logiciel d'editeur est plus complexe, la politique commerciale 
et contractuelle de l'editeur vis-a-vis de ses clients l'obligeant a maintenir en parallele 
plusieurs versions de son logiciel. 
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Le cycle de vie d'un logiciel d'editeur a Failure generale illustree a la figure 1.2. 
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Figure 1.2 

Le cycle de vie d'un logiciel d'edite 



ur 



Le cycle de vie d'un logiciel est en fait influence par le cycle de vie d'autres logiciels. Un 
logiciel est en effet le plus souvent dependant d'autres logiciels, comme les systemes 
d' exploitation, SGBD, bibliotheques de composants, etc. Le cycle de vie du materiel a 
aussi une influence, mais dans une moindre mesure, car ce cycle est beaucoup plus long. 

Cette interdependance est un facteur important de complexite pour la gestion du cycle de vie 
des logiciels, pourtant regulierement oublie par les chefs de projet. Or, du fait de la generali- 
sation des composants reutilisables, a l'image des frameworks Open Source, et des progiciels, 
cette problematique doit etre prise en compte pour assurer la perennite des investissements. 



Les lois de revolution logicielle 

Outre le taux d'echec important des projets informatiques, la crise logicielle concerne 
aussi les immenses difficultes rencontrees pour doter un logiciel d'un cycle de vie long, 
assorti d'un niveau de service convenable et economiquement rentable. 

Le professeur Meir Manny Lehman, de l'lmperial College of Science and Technology de 
Londres, a mene une etude empirique sur revolution des logiciels, en commencant par 
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analyser les changements au sein du systeme d' exploitation pour gros systemes OS/390 
d'IBM. Demarree en 1969 et encore poursuivie de nos jours, cette etude fait emerger huit lois, 
produites de 1974 a 1996, applicables a revolution des logiciels. 

Quatre de ces lois de Lehman sont particulierement signiricatives du point de vue du 
refactoring : 

• Loi du changement continuel. Un logiciel doit etre continuellement adapte, faute de 
quoi il devient progressivement moins satisfaisant a l'usage. 

• Loi de la complexite croissante. Un logiciel a tendance a augmenter en complexite, a 
moins que des actions specifiques ne soient menees pour maintenir sa complexite ou la 
reduire. 

• Loi de la croissance constante. Un logiciel doit se doter constamment de nouvelles 
fonctionnalites afin de maintenir la satisfaction des utilisateurs tout au long de sa vie. 

• Loi de la qua lite declinante. La qualite d' un logiciel tend a diminuer, a moins qu' il ne 
soit rigoureusement adapte pour faire face aux changements. 

Une des conclusions majeures des lois de Lehman est qu'un logiciel est un systeme 
fortement dependant de son environnement exterieur. Ses evolutions sont dictees par 
celui-ci selon le principe du feed-back : tout changement dans 1' environnement exterieur 
envoie un signal au sein du logiciel, dont les evolutions constituent la reponse renvoyee 
a l'exterieur. Cette reponse peut generer elle-meme des changements, engendrant ainsi 
une boucle de retroaction. 

Les forces du changement qui s'appliquent a un logiciel sont tributaires de celles qui 
s'appliquent a une entreprise. La figure 1.3 illustre quelques forces du changement 
qui poussent les logiciels a evoluer. 




Figure 1.3 

Forces du changement et evolution logicielle 
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L'erosion du design 

La loi de la croissance constante aboutit a un phenomene appele erosion du design. Au 
moment de la conception initiale du logiciel, 1' anticipation des fonctionnalites futures est 
souvent tres difficile a moyen ou long terme. De ce fait, le design d'un logiciel decoule de 
choix de conception qui etaient pertinents lors de sa creation, mais qui peuvent devenir 
invalides au fil du temps. 

Ce processus d' erosion du design fait partie des phenomenes constates par les lois de la 
qualite declinante et de la complexite croissante. Cette erosion peut devenir telle qu'il 
devienne preferable de reecrire le logiciel plutot que d'essayer de le faire evoluer a partir 
de l'existant. 

Un exemple concret de ce phenomene est fourni par le logiciel Communicator, de Netscape, 
donne en 1998 a la communaute Open Source Mozilla afin de contrer Internet Explorer 
de Microsoft. Six mois apres que le navigateur est devenu Open Source, les developpeurs 
ont considere que le moteur de rendu des pages, c'est-a-dire le coeur du navigateur, devait 
etre completement reecrit, son code source etant trop erode pour etre maintenable et 
evolutif. 

La feuille de route de la communaute Mozilla (disponible sur http://www.mozilla.org/roadmap.html) 
donne les raisons du developpement de son remplacant Gecko. En voici un extrait, suivi 
de sa traduction par nos soins : 

« Gecko stalwarts are leading an effort to fix those layout architecture bugs and design 
flaws that cannot be treated by patching symptoms. Those bugs stand in the way of major 
improvements in maintainability, footprint, performance, and extensibility. Just by redu- 
cing source code complexity, Gecko stands to become much easier to maintain, faster, 
and about as small in dynamic footprint, yet significantly smaller in code footprint. » 

« L'equipe Gecko travaille sur la correction des bogues d' architecture et des erreurs 
de conception qui ne peuvent etre traites en appliquant des patchs sur les symptomes. 
Ces bogues empechent des ameliorations majeures en maintenabilite, en consommation 
de ressources, en performance et en evolutivite. En reduisant la complexite du code, 
Gecko va devenir plus facile a maintenir, plus rapide et a peu pres similaire en terme 
de consommation de ressources bien que plus petit en terme de code. » 

En 2004, une deuxieme etape a ete franchie avec le lancement du navigateur Web Firefox 
et du client de messagerie Thunderbird, cassant definitivement le monolithisme de la 
solution Mozilla, jugee trop complexe. 

Ce phenomene d'erosion du design est une consequence de la loi de la croissance cons- 
tante. En effet, les choix de design initiaux ne tiennent pas ou pas assez compte des 
besoins futurs puisque ceux-ci ne peuvent generalement etre anticipes a moyen ou long 
terme. De ce fait, le logiciel accumule tout au long de sa vie des decisions de design non 
optimales d'un point de vue global. Cette accumulation peut etre accentuee par des 
methodes de conception iteratives favorisant les conceptions locales au detriment d'une 
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conception globale, a moins d'operer des consolidations de code, comme nous le verrons 
plus loin dans ce chapitre avec les methodes agiles. 

Meme simples, les decisions de design initiales ont des repercussions tres importantes 
sur revolution d'un logiciel, pouvant amener a operer maintes contorsions pour mainte- 
nir le niveau de fonctionnalites attendu par les utilisateurs. 

Enrin, les logiciels souffrent d' un manque de tracabilite des decisions de design, rendant 
difficile la comprehension de revolution du logiciel. Les decisions de design associees aux 
evolutions sont souvent opportunistes et tres localisees, faute d' informations suffisantes 
pour definir une strategie d' evolution. 

In fine, a defaut de solution miracle a ce probleme fondamental, seules des solutions 
palliatives sont proposees. 

Les forces du changement qui s'appliquent aux logiciels sont sans commune mesure avec 
celles qui s'appliquent aux produits industriels. Ces derniers sont concus par rapport a 
des besoins utilisateur definis a l'avance. Lorsque le produit ne correspond plus a ces besoins, 
sa production est tout simplement arretee. Dans le cadre d'un logiciel, les besoins ne sont pas 
figes dans le temps et varient meme souvent des le developpement de la premiere version. 

L'exemple des progiciels, dont la conception releve d'une approche « industrielle » (au 
sens produit), est caracteristique a cet egard. Meme en essayant de standardiser au maxi- 
mum les fonctionnalites au moyen d'un spectre fonctionnel le plus large et complet 
possible, l'effort d'adaptation a l'environnement est tres loin d'etre negligeable. Par 
ailleurs, l'arret d'un logiciel est generalement problematique, car il faut reprendre l'exis- 
tant en terme de fonctionnalites aussi bien que de donnees. 

Les solutions palliatives sont mises en oeuvre soit a priori, c'est-a-dire lors de la conception 
et du developpement initiaux, soit a posteriori, c'est-a-dire de la croissance jusqu'a la 
mort du logiciel. 

Les solutions a priori font partie des domaines du genie logiciel les plus actifs. Les 
methodes orientees objet en sont un exemple. Elles ont tente de rendre les logiciels moins 
monolithiques en les decomposant en objets collaborant les uns avec les autres selon un 
protocole defini. Tant que le protocole est maintenu, le fonctionnement interne des objets 
peut evoluer independamment de celui des autres. Malheureusement, force est de constater 
que ce n'est pas suffisant, le protocole etant le plus souvent lui-meme impacte par la 
moindre modification du logiciel. 

Une autre voie est exploree avec la POA (programmation orientee aspect), complemen- 
taire des methodes precedentes. La POA cherche a favoriser la separation franche des 
preoccupations au sein des logiciels, leur permettant de faire evoluer les composants 
d'une maniere plus independante les uns des autres. Deux preoccupations typiques d'un 
logiciel sont les preoccupations d'ordre fonctionnel, ou metier, et les preoccupations 
techniques, comme la securite, la persistance des donnees, etc. En rendant le metier inde- 
pendant de la technique, il est possible de perenniser le logiciel en limitant les impacts 
des forces du changement a une seule des deux preoccupations, dans la mesure du possible. 
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Des solutions a posteriori vont etre presentees tout au long de cet ouvrage. La problema- 
tique d'erosion du design est en effet directement adressee par le refactoring. II faut avoir 
conscience cependant que ces solutions a posteriori ne sont pas un remede miracle et que 
le refactoring n'est pas la pierre philosophale capable de transformer un logiciel mal 
congu en la quintessence de l'etat de l'art. La degenerescence du logiciel peut atteindre 
un tel degre que seul un remplacement est susceptible de regler les problemes. 

Le role de la maintenance dans I'evolution logicielle 

Situee au cceur de la problematique enoncee par les lois de Lehman, la maintenance est 
une activite majeure de l'ingenierie logicielle. C'est en partie grace a elle que le logiciel 
respecte le niveau d' exigence des utilisateurs et permet, dans une certaine mesure, que 
les investissements consacres au logiciel soient rentabilises. 

D'une maniere generate, la maintenance est un processus qui se deroule entre deux versions 
majeures d'un logiciel. Ce processus produit des correctifs ou de petites evolutions, qui 
sont soit diffuses en production au fil de l'eau, soit regroupes sous forme de versions 
mineures. 

La figure 1 .4 illustre les differentes etapes du processus de maintenance pour la gestion 
des anomalies et des evolutions mineures. 
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Figure 1.4 

Le processus de maintenance 



Pour la gestion des anomalies, appelee maintenance corrective, le processus de mainte- 
nance est tres proche de celui d'une recette. La principale difference est que la detection 
et la declaration ne sont pas realisees par des testeurs mais directement par les utilisateurs 
finals. De ce fait, la tache de correction est plus difficile. Les declarations sont generalement 
moins precises, et la reproductibilite, qui est une condition necessaire a la correction, est 
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complexifiee faute d'un scenario precis a rejouer. A cela s'ajoutent les imperatifs de 
production en terme de delais de reaction, de contraintes de diffusion, etc. 

Pour la gestion des evolutions mineures, appelee maintenance evolutive, le processus de 
maintenance s'apparente a la gestion d'un petit projet de developpement. La principale 
difference reside dans la phase d' analyse, ou une demande peut etre rejetee si elle constitue 
une evolution majeure devant etre prise en compte dans la prochaine version du logiciel. 

Signalons aussi les deux autres types de maintenance suivants : 

• Maintenance preventive : il s'agit de realiser des developpements pour prevenir des 
dysfonctionnements futurs. 

• Maintenance adaptative : il s'agit d' adapter le logiciel aux changements survenant 
dans son environnement d' execution. 

En conclusion, la caracteristique des activites de maintenance par rapport a un projet de 
developpement est leur duree. Sur 1' ensemble de la vie d'un logiciel, la duree de la main- 
tenance est generalement superieure a celle du developpement. Le cycle developpement- 
mise en production est beaucoup plus court pour la maintenance et comprend de 
nombreuses iterations. 

Maintenance et refactoring 

Comme vous le verrez tout au long de l'ouvrage, le refactoring est une activite de main- 
tenance d'un genre particulier. II s'agit non pas d'une tache de correction des anomalies 
ou de realisation de petites evolutions pour les utilisateurs mais d'une activite plus proche 
de la maintenance preventive et adaptative dans le sens ou elle n'est pas directement visible 
de l'utilisateur. 

Le refactoring est une activite d'ingenierie logicielle consistant a modifier le code source 
d'une application de maniere a ameliorer sa qualite sans alterer son comportement du 
point de vue de ses utilisateurs. Son role concerne essentiellement la perennisation de 
l'existant, la reduction des coiits de maintenance et 1' amelioration de la qualite de service 
au sens technique du terme (performance et fiabihte). Le refactoring est en ce sens different 
de la maintenance corrective et evolutive, qui modifie directement le comportement du 
logiciel, respectivement pour corriger un bogue ou ajouter ou ameliorer des fonctionnalites. 

Par ailleurs, la maintenance a generalement une vision a court terme de revolution du 
logiciel puisqu'il s'agit de repondre a l'urgence et d'etre reactif. Le refactoring est une 
demarche qui vise a pallier activement les problemes de revolution logicielle, notam- 
ment celui de l'erosion. II s'agit done d'une activite au long court, devant etre dotee 
d'une feuille de route continuellement mise a jour au gre des changements. 

Idealement, le refactoring doit etre envisage comme un processus continu plutot que 
comme un chantier devant etre mene ponctuellement. II peut etre effectue en parallele de 
la maintenance des lors qu'il est compatible avec ses contraintes de reactivite. A l'instar 
de la correction d'erreur, plus un refactoring est effectue tot moins il coute cher. 
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Le perimetre d'intervention du refactoring 

Vous avez vu a la section precedente comment situer le refactoring par rapport a la 
problematique de revolution logicielle et a l'activite de maintenance. La presente section 
se penche sur le perimetre d'intervention du refactoring. 

Le refactoring etant un processus delicat, nous donnons une synthese dont il importe de 
bien mesurer les benefices et les risques lies a sa mise en oeuvre. Ainsi, la reduction de la 
complexite du code via un refactoring entraine normalement une diminution des couts de 
maintenance. Cependant, en fonction de l'importance des modifications a apporter au 
code, les couts de transformation et les risques peuvent devenir redhibitoires. 

Pour toutes ces raisons, il est essentiel d'anticiper le refactoring des la conception 
d'un logiciel. 

Les niveaux de refactoring 

Nous pouvons considerer trois niveaux de refactoring, selon la complexite de sa mise en 
ceuvre : le refactoring chirurgical, le refactoring tactique et le refactoring strategique. 

Le refactoring chirurgical 

Par refactoring chirurgical, nous entendons la realisation d' operations de refactoring 
limitees et localisees dans le code source. 

II s'agit de refondre quelques composants sans alterer leurs relations avec le reste du 
logiciel. Nous utilisons typiquement les techniques de base detaillees dans la premiere 
partie de cet ouvrage. 

De telles operations sont tout a fait realisables dans le cadre de la maintenance puis- 
que leur perimetre limite ne justifie pas la mise en place d'une structure de projet ad 
hoc. Elle est particulierement pertinente pour consolider certaines operations de 
maintenance realisees pour repondre a l'urgence mais nuisant a la qualite generale du 
logiciel. 

Le refactoring tactique 

Par refactoring tactique, nous entendons la refonte complete de quelques composants 
repenses tant dans leur fonctionnement interne que dans leurs relations avec le reste du 
logiciel. II peut s'agir, par exemple, d'introduire des design patterns dans le code, comme 
nous l'expliquons au chapitre 6. 

Ce type d'operation est plus difficile a realiser de maniere integree a la maintenance. 
L effort de test pour valider le refactoring peut en effet devenir rapidement incompati- 
ble avec la reactivite necessaire aux corrections de bogues ou aux evolutions deman- 
dees en urgence. Cependant, la structure projet a mettre en place reste generalement 
limitee. 
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Le refactoring strategique 

Par refactoring strategique, nous entendons la remise a plat de la conception du logiciel afin 
de l'adapter aux exigences presentes et futures des utilisateurs. Dans ce cadre, l'ensemble 
des techniques presentees dans cet ouvrage sera vraisemblablement mis en oeuvre. 

La frontiere entre ce refactoring et une reecriture pure et simple du logiciel est si tenue 
qu'il est essentiel de bien reflechir aux objectifs a atteindre. La demarche de refactoring 
strategique est evidemment inutile si, in fine, nous devons reecrire le logiciel. 

La phase d' analyse du logiciel doit etre particulierement soignee de maniere a definir et 
chiffrer une strategie de refonte. Cette strategic doit etre comparee a une reecriture ou a 
un remplacement par un progiciel et ponderee par les facteurs de risque lies a chacune de 
ces demarches. 

Le processus de refactoring 

Le processus de refactoring compte les quatre phases principales suivantes, dont la 
premiere est generalement mise en oeuvre des la creation du logiciel : 

1 . Mise en place de la gestion du changement. 

2. Analyse du logiciel. 

3. Refonte du code. 

4. Validation du refactoring. 

Mise en place de la gestion du changement 

Le developpement d'un logiciel necessite 1' utilisation d'une infrastructure pour gerer les 
changements qu'il subira tout au long de sa vie. Cette infrastructure de gestion du chan- 
gement est articulee autour de trois themes : 

• Gestion de configuration, qui concerne la gestion des versions successives des composants 
du logiciel. 

• Gestion des tests, qui permet de valider le fonctionnement du logiciel en regard des 
exigences des utilisateurs. 

• Gestion des anomalies, qui concerne la gestion du cycle de vie des anomalies detectees 
par les recetteurs ou les utilisateurs finals. 

Cette infrastructure est generalement mise en place lors de la creation du logiciel. Elle 
peut etre artisanale, c'est-a-dire geree manuellement sans l'aide d'outils specialises, dans 
le cadre de projets de taille modeste. 

La mise en place d'une telle infrastructure peut sembler au premier abord inutilement 
couteuse et lourde a mettre en oeuvre. Si ce raisonnement peut se tenir pour la premiere 
version, il n'en va pas de meme si nous considerons le cycle de vie dans sa globalite. La 
contrainte forte du refactoring, qui consiste a ne pas modifier le comportement du logiciel 
du point de vue des utilisateurs, necessite une infrastructure de gestion du changement 
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solide afin de se derouler avec un maximum de securite (grace, par exemple, a la possibi- 
lite de faire marche arriere au cours d'une operation de refactoring non concluante). Dans 
cette perspective, la mise en place d'une telle infrastructure est vite rentabilisee. 

Analyse du logiciel 

L' analyse du logiciel consiste a detecter les composants candidats au refactoring au sein 
du code du logiciel. Cette analyse est a la fois quantitative et qualitative. 

L' analyse quantitative consiste a calculer differentes metriques sur le logiciel. Ces 
metriques sont comparees avec les regies de l'art pour identifier les zones problema- 
tiques. Malheureusement imparfaites, puisqu'elles peuvent signaler des anomalies la 
ou il n'y en a pas (fausses alertes) et passer a cote de problemes serieux (faux amis), ces 
metriques ne beneficient pas de la meme fiabilite que les metriques physiques, par 
exemple. 

De ce fait, 1' analyse qualitative est cruciale pour le refactoring puisque c'est par le 
biais de ses resultats que nous pouvons decider des zones a refondre. Cette analyse 
consiste essentiellement a auditer le code manuellement ou a l'aide d'outils et a revoir 
la conception du logiciel pour detecter d'eventuelles failles apparues au cours de la vie 
du logiciel. 

Pour optimiser cette phase d' analyse qualitative, qui peut se reveler extremement couteuse 
et done peu rentable, nous effectuons des sondages guides par les resultats obtenus lors 
de 1' analyse quantitative. 

A partir de la liste des zones a refondre identifiees lors de cette phase, nous devons decider 
quelles seront celles qui devront effectivement l'etre. Pour cela, il est necessaire d'evaluer, 
pour chacune d'elles, le cout de la refonte, le gain attendu en terme de maintenabilite ou 
d'evolutivite et les risques associes a cette refonte. 

Les risques peuvent etre deduits d'une analyse d'impact. Une modification strictement 
interne a une classe est generalement peu risquee alors que la mise en ceuvre d'un design 
pattern peut avoir des impacts tres importants sur 1' ensemble du logiciel. 

Refonte du code 

Une fois les zones a refondre selectionnees, la refonte du code peut commencer. Le souci 
majeur lors d'une operation de refactoring est de s' assurer que les modifications du code 
source n'alterent pas le fonctionnement du logiciel. De ce fait, avant toute modification 
du code, il est necessaire de mettre au point une batterie de tests sur le code originel si 
elle n'existe pas deja. lis seront utiles pour la phase de validation. 

Lorsque les tests de non-regression sont valides sur le code originel, nous pouvons effec- 
tuer la refonte proprement dite. Pour faciliter la validation du refactoring, il est recom- 
mande de realiser une validation a chaque operation de refactoring unitaire. Si nous accu- 
mulons un grand nombre de modifications non testees, toute erreur detectee devient plus 
difficile a corriger. 



L'evolution logicielle et le refactoring 

Chapitre 1 

Validation du refactoring 

La phase de validation du refactoring consiste a verifier si la contrainte de non-modification 
du logiciel a ete respectee. 

Pour realiser cette validation, nous nous reposons sur la batterie de tests mise en place en 
amont de la refonte. II est done important que ces tests soient le plus exhaustifs possible 
afin de valider le plus de cas de figure possible. 

Ces tests de validation soulignent une fois de plus 1' importance de la gestion du change- 
ment pour un logiciel. Lors de la creation du logiciel, des tests ont ete specifies pour 
effectuer sa recette. Si aucune demarche de capitalisation des tests n'a ete mise en place, 
le cout du refactoring n'est pas optimise puisqu'une partie de ceux-ci doivent etre recrees 
ex nihilo. 

Une fois la refonte validee, nous pouvons livrer la nouvelle version du logiciel aux utili- 
sateurs finals. Comme pour toute nouvelle version, une partie de l'equipe projet doit etre 
maintenue le temps necessaire pour assurer le transfert de competence vers l'equipe de 
maintenance. Des bogues seront en effet inevitablement detectes par les utilisateurs et 
devront etre rapidement corriges. 

Benefices et challenges du refactoring 

Comme nous l'avons vu aux sections precedentes, le refactoring d'un logiciel n'est 
jamais une operation anodine. II est essentiel de mesurer les benefices et challenges lies a 
sa mise en ceuvre pour decider de l'opportunite de son utilisation. 

Les benefices du refactoring 

L'objectif du refactoring est d' ameliorer la qualite du code d'un logiciel. En ameliorant 
la qualite du code, nous cherchons a optimiser sa maintenabilite et son evolutivite afin de 
rentabiliser les investissements tout au long de la vie du logiciel. 

Pour ameliorer la maintenabilite d'un logiciel, nous cherchons principalement a reduire 
sa complexite et a diminuer le nombre de lignes de code a maintenir. Ce dernier point 
consiste souvent a chasser les duplications de code au sein du logiciel. Comme le montre 
l'etude de cas de la partie III de l'ouvrage, cette traque aux dupliquas peut etre particulie- 
rement lourde. 

Pour ameliorer 1' evolutivite d'un logiciel, garante de sa perennite, nous cherchons princi- 
palement a faire reposer le logiciel sur des standards. Par ailleurs, le respect des meilleures 
pratiques, pour beaucoup formalisees sous forme de design patterns, est souvent un gage 
de meilleure evolutivite du logiciel. La mise en oeuvre de ces modeles ne va toutefois pas 
sans poser de problemes, comme nous le verrons a la section suivante. 

Les challenges du refactoring 

Le premier challenge du refactoring consiste a. . . le « vendre ». Dans la mesure ou le 
refactoring n'offre pas de gains directement visibles des utilisateurs finals, ceux-ci ont 
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une certaine difficulte a y adherer. Si les utilisateurs finals sont detenteurs des budgets 
affectes au logiciel, leur tentation de favoriser les evolutions par rapport a une consolidation 
du code existant est evidemment forte. 

Pour les convaincre de realiser une ou plusieurs operations de refactoring, il est neces- 
saire de bien connaitre les couts associes a la maintenance et a revolution du logiciel et 
d'etre en mesure, suite a une analyse, de demontrer que l'investissement dans le refactoring 
est rentable. 

L'ideal est d'injecter des operations de refactoring tout au long du processus de mainte- 
nance de maniere a rendre l'operation plus indolore pour les utilisateurs finals. Malheu- 
reusement, ce n'est pas toujours possible, ce mode de fonctionnement dependant forte - 
ment de la qualite initiale du logiciel. Compte tenu des depassements de delai ou de 
budget que Ton constate dans la majorite des projets informatiques, la tendance reste a 
mettre le logiciel en production le plus rapidement possible. 

Le deuxieme challenge du refactoring reside dans revaluation des risques a l'entrepren- 
dre compares a ceux de ne rien faire. Dans certains cas, il peut etre preferable de laisser 
les choses en l'etat plutot que de se lancer dans une operation dont les chances de succes 
sont faibles. 

II est done necessaire, dans la mesure du possible, d'evaluer le perimetre de la refonte en 
analysant les impacts lies aux modifications du code source. Cela n'est malheureusement 
pas toujours possible, car les composants d'un logiciel peuvent etre extremement depen- 
dants les uns des autres, induisant des effets de bord difficilement controlables lorsque 
l'un d'eux est modifie. 

Le refactoring n'est efficace que sur un logiciel dont les fondements sont sains. Si les 
fondements du logiciel sont mauvais, le refactoring n'est pas la demarche adaptee pour y 
remedier. Seule une reecriture ou un remplacement par un progiciel, que nous pouvons 
esperer mieux concu, permet de solutionner ce probleme. 

Le troisieme challenge du refactoring est de motiver les equipes de developpeurs pour 
refondre le code. Ce type d' operation peut etre percu, a tort de notre point de vue, comme 
une tache ingrate et peu valorisante. Par ailleurs, les developpeurs font toujours preuve de 
reticence pour modifier le code d'un autre, du simple fait de la difficulte a le comprendre. 

Pour les projets de refactoring lourds, qui ne peuvent etre integres a la maintenance, il est 
important de bien communiquer pour demontrer l'interet de la demarche et justifier le 
defi qu'elle represente pour les developpeurs. 

Anticipation du refactoring 

La meilleure facon d'anticiper le refactoring est de bien concevoir le logiciel des l'origine 
afin de lui donner le plus de flexibilite possible face aux evolutions qu'il connaitra tout au 
long de sa vie. Pour cela, il est necessaire de se reposer sur les meilleures pratiques en la 
matiere, formalisees notamment sous forme de design patterns. 
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II est important de separer au maximum les preoccupations (metiers et techniques, par 
exemple), de maniere a limiter les effets de bord lors d'un refactoring. Cette separation 
peut reposer sur la POA, mais ce n'est pas obligatoire. II existe d'autres techniques, 
comme 1' inversion de controle proposee par les conteneurs legers de type Spring. 

L'avenir du logiciel doit etre anticipe dans la mesure du possible afin de pallier l'erosion 
logicielle, qui est en elle-meme ineluctable. La tracabilite des decisions de conception 
doit etre assuree pour servir de base a l'analyse du logiciel dans le cadre des operations 
de refactoring. 

Un soin particulier doit etre apporte a la programmation et a la documentation du code. 
Des langages tels que Java disposent de regies de bonne programmation, qu'il est primor- 
dial de respecter. Plus le code est correctement documente, plus il est facile de le refondre 
puisqu'il est mieux compris. 

Enfin, il est necessaire de capitaliser sur les tests afin de rendre le refactoring efficace. 
Plus les tests sont complets, plus nous avons des garanties de non-regression du logiciel 
refondu. Cette capitalisation peut etre notamment assuree par la mise en place d'une 
infrastructure de tests automatises, comme nous le verrons au chapitre 5. Maine ureuse- 
ment, les tests sont souvent les parents pauvres des developpements, car ils ne sont le 
plus souvent utilises qu'en tant que variable d'ajustement pour respecter les delais. 



Le refactoring au sein des methodes agiles 

Les methodes agiles sont de nouvelles approches de modelisation et de developpement 
logiciel. Leur objectif fondamental est de produire rapidement des logiciels correspondant 
aux besoins des utilisateurs en associant ces derniers a un processus iteratif favorisant la 
communication avec les informaticiens. 

Ce processus, qui n'est pas sans rappeler les methodes RAD (Rapid Application Develo- 
pment), necessite d'introduire des phases de refactoring importantes afin de consolider le 
code produit a chaque iteration. 

C'est la raison pour laquelle il nous semble utile d'etudier specifiquement le role du 
refactoring en leur sein. 

Le manifeste du developpement logiciel agile 

En 2001, plusieurs experts, parmi lesquels Kent Beck, Ron Jeffries et Martin Fowler, un 
des peres du refactoring, se reunissent lors d'un atelier a Snowbird, aux Etats-Unis, pour 
reflechir a de nouvelles approches de modelisation et de developpement logiciel, incar- 
nees par XP (eXtreme Programming) ou DSDM (Dynamic System Development Metho- 
dology). 

Ils tirent de leurs reflexions un manifeste jetant les bases des methodes agiles (voir http:// 
agilemanifesto.org/), dont voici des extraits en anglais, suivis d'une traduction par nos soins : 
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"We are uncovering better ways of developing software by doing it and helping others 
do it. Through this work we have come to value: 

- Individuals and interactions over processes and tools. 

- Working software over comprehensive documentation. 

- Customer collaboration over contract negotiation. 

- Responding to change over following a plan. 

That is, while there is value in the items on the right, we value the items on the left 
more." 

Traduction : 

« Nous decouvrons de nouvelles facons de developper des logiciels en le faisant et en 
aidant les autres a le faire. Au travers de ce travail, nous en sommes venus a privilegier : 

- Les individus et les interactions par rapport aux processus et aux outils. 

- Les logiciels qui fonctionnent par rapport a une documentation complete. 

- La collaboration avec les utilisateurs par rapport a une negotiation contractuelle. 

- La reponse aux changements par rapport au respect d'un plan. 

Ainsi, meme si les elements de droite sont importants, ceux de gauche le sont plus 
encore a nos yeux. » 

De ce manifeste decoulent une douzaine de principes devant etre respectes par les methodes 
agiles : 

Accorder la plus haute priorite a la satisfaction de l'utilisateur grace a une diffusion 
rapide et continue d'un logiciel opera tionnel. 

Accepter les changements apparus dans l'expression des besoins, meme tardivement 
pendant le developpement. Les processus agiles doivent etre en mesure de supporter le 
changement pour garantir l'avantage competitif du client. 

Diffuser des versions operationnelles du logiciel a echeance reguliere, de toutes les deux 
semaines jusqu'a tous les deux mois, avec une preference pour la frequence la plus courte. 

Faire travailler ensemble quotidiennement utilisateurs et developpeurs tout au long du 
projet. 

Construire le projet avec des personnes motivees en leur fournissant l'environnement 
et le support dont elles ont besoin et en leur faisant confiance. 

Privilegier la conversation face a face, qui est le moyen le plus efficace pour trans- 
mettre de 1' information a et dans une equipe de developpement. 

Considerer les versions operationnelles du logiciel comme les mesures principales du 
progres. 

Considerer les precedes agiles comme les moteurs d'un developpement viable. Sponsors, 
developpeurs et utilisateurs doivent pouvoir maintenir un rythme constant indefiniment. 

Apporter une attention continue a 1' excellence technique et a la bonne conception afin 
d'ameliorer l'agilite. 
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• Privilegier la simplicity, c'est-a-dire l'art de maximiser le travail a ne pas faire. 

• Considerer que les meilleures architectures, expressions de besoins et conceptions 
emergent d'equipes auto-organisees. 

• Reflechir a intervalle regulier a la facon de devenir plus efficace et agir sur le compor- 
tement de l'equipe en consequence. 

La position des auteurs du manifeste est resolument pragmatique. Elle part du constat 
que rien ne peut arreter les forces du changement et qu'il vaut mieux composer avec. 

En rupture totale avec le celebre cycle en V, ces principes sont cependant loin de faire 1' unani- 
mite aupres des informaticiens et de leurs utilisateurs. Leur mise en oeuvre represente par 
ailleurs de veritables defis pour nos organisations actuelles. 

Les methodes agiles 

Plusieurs methodes agiles sont disponibles aujourd'hui, dont nous presentons dans les 
sections suivantes quelques-unes parmi les plus significatives : 

• XP (eXtreme Programming) 

• ASD (Adaptive Software Development) 

• FDD (Feature Driven Development) 

• TDD (Test Driven Development) 

XP (extreme Programming) 

L' eXtreme Programming est certainement la methode agile la plus connue. Elle definit 
treize pratiques portant sur la programmation, la collaboration entre les differents acteurs 
et la gestion de projet. 

Cette methode fait apparaitre dans ses principes fondateurs l'utilisation systematique du 
refactoring pour garantir une qualite constante aux versions livrees aux utilisateurs. 

Par rapport aux principes du manifeste, 1' eXtreme Programming introduit les elements 
novateurs suivants : 

• Le developpement pilote par les tests. Les tests unitaires ont une importance majeure 
dans la demarche XP. Ceux-ci doivent etre realises avant meme le developpement 
d'une fonctionnalite afin de s'assurer de la bonne comprehension des besoins des utili- 
sateurs. En effet, l'ecriture de tests oblige a adopter le point de vue de l'utilisateur et, 
pour cela, a bien comprendre ce qu'il attend. 

• La programmation en binome. La programmation en binome est certainement un des 
principes les plus perturbants pour les lecteurs habitues aux methodes de developpement 
traditionnelles. II s'agit ici de faire travailler les developpeurs deux par deux. Chaque 
binome travaille sur la meme machine et sur le meme code afin de traiter plus rapidement 
les problemes et d'ameliorer le controle du code produit. Les binomes ne sont pas fixes 
dans le temps, et de nouvelles associations se font jour tout au long du projet. 
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• La responsabilite collective du code. Dans une organisation classique, les developpeurs 
se voient generalement attribuer une partie du code du logiciel sous leur responsabilite. 
Rien de tel avec XP, tout developpeur etant susceptible d'intervenir sur n'importe 
quelle partie du code. De ce fait, la responsabilite du code est collective. 

• L'integration continue. Pour garantir une consistance du code produit et livrer rapi- 
dement des versions opera tionnelles du logiciel aux utilisateurs, l'XP recommande de 
realiser des integrations tres frequentes du code produit par les differents developpeurs. 
La frequence minimale recommandee est une fois par jour. 

• Le refactoring. Le refactoring est une activite majeure de l'XP C'est grace a lui que 
la qualite du code est garantie tout au long des iterations. Son role est aussi de faire 
emerger 1' architecture du logiciel, depuis les phases initiates jusqu' a sa livraison defi- 
nitive aux utilisateurs. 

ASD (Adaptive Software Development) 

LASD est fonde sur le principe de 1' adaptation continue du fait de la necessite d' accepter 
les changements continuels qui s'imposent aux logiciels. Ainsi, l'ASD est organise autour 
d'un cycle en trois phases (speculation, collaboration et apprentissage) en remplacement 
du cycle classique des projets informatiques (planification, conception et construction). 

La speculation 

La speculation comporte les cinq etapes suivantes : 

1. Initialisation du projet, definissant la mission affectee au projet. 

2. Planification generale du projet limitee dans le temps. Toute l'organisation du projet 
est centree sur le respect de cette limite. 

3. Definition du nombre d' iterations a effectuer et de leur date limite de livraison afin de 
respecter la limite globale du projet. 

4. Definition du theme ou des objectifs de chaque iteration. 

5. Definition en concertation par les developpeurs et les utilisateurs du contenu fonc- 
tionnel de chaque iteration. 

La collaboration 

Pendant que l'equipe technique livre des versions operationnelles du logiciel, les chefs 
de projet facilitent la collaboration et les developpements en parallele afin de respecter le 
planning du projet et les besoins des utilisateurs. 

L'apprentissage 

A la fin de chaque iteration, une phase d' apprentissage est prevue. Cette phase est desti- 
nee a obtenir le feed-back le plus exhaustif possible sur la version livree afin d'ameliorer 
continuellement le processus. Le focus est mis sur la qualite du resultat, a la fois du point 
de vue des utilisateurs et du point de vue technique, ainsi que sur l'efficacite du mode de 
fonctionnement de l'equipe. 
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FDD (Feature Driven Development) 

Contrairement aux methodes precedentes, le FDD debute par une phase de conception 
generale, qui vise a specifier un modele objet du domaine du logiciel en collaboration 
avec les experts du domaine. 

Une fois le modele du domaine specifie et un premier recueil des besoins des utilisateurs 
effectue, les developpeurs dressent une liste de fonctionnalites a implemented La planifi- 
cation et les responsabilites sont alors definies. 

Le developpement du logiciel autour de la liste des fonctionnalites suit une serie d' iterations 
tres rapides, au rythme d'une iteration toutes les deux semaines au maximum, composees 
chacune d'une etape de conception et d'une etape de developpement. 

TDD (Test Driven Development) 

Le TDD place les tests au centre du developpement logiciel. II s'agit d'une demarche 
complementaire des methodes plus globales, comme l'XP, mais centree sur le developpe- 
ment. 

Chaque developpement de code, meme le plus petit, est systematiquement precede du 
developpement de tests unitaires permettant de specifier et verifier ce que celui-ci doit 
faire. Puisque les tests portent sur du code qui n'existe pas encore, ils echouent si nous 
les executons. Nous pouvons des lors ne developper que le code necessaire et suffisant 
pour que les tests reussissent. 

Un refactoring est ensuite effectue pour optimiser a la fois les tests et le code teste, 
notamment en supprimant la duplication de code. Au fur et a mesure de l'avancee du 
projet, de plus en plus de tests sont developpes, la regie etant que tout nouveau code 
ajoute ne doive pas les faire echouer. 

Les iterations du TDD sont beaucoup plus courtes qu'en XP puisqu'elles s'enclenchent a 
chaque morceau de code significatif, comme une methode de classe. Leur frequence 
varie done de quelques minutes a une heure environ. 

En procedant de la sorte, nous garantissons le respect des specifications et la non-regression 
a chaque iteration. 

Role du refactoring dans les methodes agiles 

Comme nous venons de le voir, le refactoring est une activite cle des methodes agiles. Un 
des peres du refactoring, Martin Fowler, est d'ailleurs a l'origine du manifeste du deve- 
loppement agile. 

L ensemble des methodes agiles fonctionne sur un mode iteratif. Cela favorise 1' emergence 
d'une version finale du logiciel adaptee aux besoins des utilisateurs en leur delivrant a chaque 
iteration une version operationnelle, mais non finalisee fonctionnellement, du logiciel. 

Pour ne pas etre victime de l'erosion du design, il est fondamental pour les methodes 
agiles d'utiliser le refactoring afin de consolider leur code d'une version a une autre. Ce 
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mode de fonctionnement exige d'anticiper le refactoring, en appliquant des le depart les 
meilleures pratiques de conception et de programmation arm de minimiser l'effort de 
refactoring. 

Comme nous le verrons dans les chapitres suivants de cet ouvrage, le processus de refac- 
toring est tres bien outille des lors que les refontes a mener sont simples. II est done 
important d' assurer 1' emergence d'une architecture solide lors des differentes iterations 
et de ne pas sombrer dans la tentation du quick and dirty. 

Le processus de refactoring est particulierement bien anticipe dans les methodes agiles 
telles que XP ou TDD grace a la capitalisation des tests unitaires. 

Conclusion 

Vous avez vu dans ce chapitre introductif comment le refactoring se positionnait par 
rapport a aux problematiques generates d' evolution logicielle et de maintenance. 

Vous decouvrirez dans les chapitres de la premiere partie de 1' ouvrage comment mettre 
en oeuvre le processus de refactoring, depuis la mise en place de 1' infrastructure de gestion 
du changement jusqu'a la validation du logiciel refondu. 



Partie I 



Le processus 
de refactoring 



A l'instar de tout projet logiciel, le refactoring s'inscrit dans un processus comportant 
les etapes fondamentales suivantes : 

1. La preparation, qui consiste a mettre en place, si ce n'est deja fait, les outils 
permettant de gerer les changements et les valider. 

2. L' analyse du logiciel, qui consiste a identifier les elements du logiciel necessitant 
un refactoring et a selectionner ceux qui sont pertinents. 

3. La realisation des operations de refactoring. 

4. La validation du refactoring, qui consiste a verifier la non-regression du logiciel du 
point de vue des utilisateurs, tant pour les aspects fonctionnels que pour la qualite 
de service. 

5. Si le logiciel en cours de refactoring subit des maintenances correctives en parallele, 
une fusion de la version de maintenance et de la version de refactoring est necessaire. 
Des points de synchronisation doivent etre mis en place, comme nous le verrons au 
chapitre 2. 

Le processus que nous venons de decrire considere implicitement que le refactoring 
est un projet en lui-meme. Cependant, du fait de sa nature quelque peu esoterique pour 
les utilisateurs, puisqu'il s'agit d'une serie d'operations techniques, le refactoring est 
rarement applique en dehors des projets d'evolution ou de maintenance des logiciels. 

Cette integration du refactoring au sein d'un projet ay ant un perimetre plus large ne 
remet pas en cause les etapes fondamentales ci-dessus, car celles-ci sont propres a tout 
projet d'evolution, qu'il soit technique ou fonctionnel. Ces etapes doivent simplement 
integrer les problematiques specifiques des autres types d'evolution. Dans le cas des 
methodes agiles, l'etape de refactoring est clairement identifiee et s'inscrit de maniere 
visible dans la demarche projet. 

Les chapitres de cette partie s'attachent a decrire en detail les differentes etapes du 
refactoring. 
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Comme tout projet logiciel, notamment de maintenance, le refactoring necessite une 
phase de preparation arm de s' assurer que les operations se deroulent dans les meilleures 
conditions. 

La phase de preparation du refactoring est centree sur la gestion du changement. Cette 
gestion s'appuie sur deux piliers : 

• La gestion de configuration, c'est-a-dire l'utilisation d'un outil permettant de gerer les 
evolutions successives des ressources composant le logiciel ainsi que les acces simultanes 
a ces dernieres. 

• La gestion des tests et des anomalies, c'est-a-dire la definition d'une strategie de tests 
permettant d' assurer le bon deroulement du refactoring. 

Idealement, ces deux piliers sont mis en place des la creation du logiciel. Cela raccourcit 
sensiblement la phase de preparation en la centrant sur la definition de tests specifiques 
au refactoring. Dans le cas contraire, la phase de preparation consiste en la mise en place 
d'une gestion des changements complete. 

Ce chapitre decrit de maniere synthetique les deux piliers de la gestion des changements 
et presente rapidement les outils afferents qui sont utilises dans cet ouvrage (leur mode 
de fonctionnement est aborde plus en detail dans l'etude de cas de la partie III). 

La gestion de configuration 

La gestion de configuration, aussi appelee gestion de version, est le premier pilier de la gestion 
des changements d'un logiciel. C'est sur elle que reposent l'archivage des modifications 
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successives des differentes ressources composant le logiciel et la definition de ses diffe- 
rentes versions. 

Les ressources sont des fichiers. II s'agit generalement du code source, mais cela peut 
aussi concerner des fichiers binaires, comme des images ou des bibliotheques externes. 
Les ressources sont regroupees sous forme de projets, de maniere a permettre de gerer 
plusieurs projets au sein du meme outil de gestion de configuration. Chaque projet suit un 
cycle de vie qui lui est propre, que nous decrivons plus loin dans ce chapitre. 

La gestion de configuration prend tout son sens lorsque les projets impliquent plusieurs 
developpeurs ou possedent au moins deux versions simultanement, une de maintenance 
corrective et une d' evolution, par exemple. 

Les principes 

Tout composant d'un logiciel est destine a evoluer, depuis son prototype jusqu'a sa 
version courante. De plus, des que le projet implique plus d'un developpeur, le partage 
des ressources composant le logiciel est incontournable. Le principe fondateur de la 
gestion de configuration est de mettre en place un referentiel unique permettant de partager 
les ressources entre plusieurs developpeurs et de tracer les evolutions. 

Les avantages d'un outil de gestion de configuration sont les suivants : 

• Mieux securiser 1' infrastructure de developpement en concentrant en un point unique 
les ressources composant le logiciel. Par exemple, la perte d'un poste de travail d'un 
developpeur a moins de consequences si la totalite du code source est stockee sur un 
serveur, avec des disques redondants et une politique de sauvegarde rigoureuse. 

• Conserver la trace de toutes les modifications operees sur les ressources. Ainsi, une 
modification irreflechie d'une ressource peut etre corrigee a partir des versions ante- 
rieures stockees dans le referentiel. 

• Faciliter le travail en equipe puisque les ressources, en particulier le code source, sont 
partagees par tous, avec, le cas echeant, une gestion des autorisations si cela s'avere 
necessaire dans le contexte du projet. 

• Gerer plusieurs versions d'un meme logiciel en parallele et assurer des synchronisations 
entre elles grace a la notion de branche. 

Lutilisation d'outils de gestion de configuration est courante dans les projets Open Source. 
Le site Web communautaire SourceForge.net (http://www.sourceforge.net), par exemple, qui 
offre une infrastructure de developpement et de diffusion pour des dizaines de milliers de 
projets Open Source, propose l'outil de gestion de configuration CVS (Concurrent 
Versions System). Grace a ce dernier, des developpeurs du monde entier peuvent collaborer 
en vue de la realisation, de la maintenance ou de revolution de projets Open Source de 
toute sorte. 
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L' inconvenient des outils de gestion de configuration est leur lourdeur d'utilisation. Un 
referentiel unique, partage par tous, implique en effet le suivi d'un processus specifique 
de modification des composants, plus contraignant que lorsque les developpeurs travaillent 
chacun sur leur poste. Cette rigueur imposee dans la gestion des modifications est cependant 
largement compensee par les capacites de ces outils a gerer le travail en equipe et le cycle 
de vie des composants. 

Gestion des modifications de ressources 

Les outils de gestion de configuration proposent un referentiel unique de ressources, 
partage par tous les developpeurs. A tout moment, plusieurs d'entre eux peuvent etre 
amenes a modifier une meme ressource. 

Ces modifications multiples par des intervenants differents sont generalement difficilement 
gerables manuellement, car elles demandent beaucoup de manipulations (acquisition, 
liberation, comparaison, synchronisation et mise a jour) et sont sujettes a erreur. 

Les outils de gestion de configuration peuvent traiter les acces concourants aux donnees 
selon deux strategies differentes, inspirees du fonctionnement des systemes de gestion de 
bases de donnees, le verrou et la fusion. 

Le verrou 

Le verrou est la strategie la plus securisee, mais aussi la plus contraignante pour 1' acces 
simultane en modification a une ressource par differents developpeurs. Le premier qui 
demande 1' acces en modification obtient un acces exclusif a la ressource. Cette demande 
est appelee check-out. Les autres developpeurs sont contraints d'attendre que la 
ressource soit liberee pour pouvoir la modifier. Cette liberation est appelee commit, ou 
check-in. Elle consiste en la mise a jour de la ressource dans le referentiel (creation d'une 
nouvelle revision) et en la suppression du verrou pour rendre le check-out a nouveau 
possible. Bien entendu, une fois la ressource liberee, un seul developpeur peut faire un 
check-out, et ainsi de suite. 

La figure 2.1 illustre le fonctionnement du verrou pour une ressource R demandee par 
deux developpeurs (les numeros indiquent la sequence chronologique des actions). 

Cette strategie garantit que les modifications d'une ressource sont consistantes puisque la 
simultaneity est bloquee. Les developpeurs en attente de la ressource ont toujours la 
possibilite de recuperer la ressource en lecture seule. Cela leur permet d'effectuer des 
modifications en local en attendant que la ressource soit liberee. 

Si elle n'est pas utilisee de maniere tres rigoureuse, la strategie du verrou peut devenir 
rapidement problematique. Imaginez un developpeur obtenant un acces en modification 
sur une multitude de ressources et oubliant de les liberer avant de partir en vacances. 
Bien entendu, les outils proposant ce type de strategie permettent de casser les verrous, 
mais le cout d'une telle operation est loin d'etre negligeable en terme d' administration. 



Le processus de refactoring 

Partie I 



1 . Pose du verrou 
(check-out) 



Referentiel 



^ 



▲ l ▲ 



3. Mise a jour de R 

-et liberation du verrou- 

(commit) 



1'. Tentative de pose du verrou 



4. Pose du verrou 
(check-out) 







2. Recuperation d'une copie 

de R sur le poste de travail 

pour modification 




Developpeur A 

Figure 2.1 

Fonctionnement du verrou 
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Par ailleurs, dans la mesure ou le verrou se fixe au niveau de la ressource, il empeche 
inutilement la realisation de modifications compatibles entre elles. Par exemple, si la 
ressource est une classe possedant plusieurs methodes et que chacune d' entre elles soit 
sous la responsabilite exclusive d'un seul et unique developpeur, pourquoi empecher 
1' ensemble de ces developpeurs de travailler en meme temps sur cette classe ? Sous 
reserve qu'ils n'aient pas a modifier les elements communs de la classe, leurs modifications 
sont compatibles entre elles et ne generent pas de conflit. 

Enfin, cette strategic donne une fausse impression de securite au developpeur du fait de 
son acces exclusif a la ressource. Les modifications d'une ressource publiees tardivement 
peuvent entrainer une inconsistance, car elles ne favorisent pas les points de synchronisation, 
a la difference de la strategie de fusion presentee ci-dessous. 



La fusion 

La fusion est une strategie beaucoup moins contraignante que le verrou, qui permet un 
veritable acces simultane en modification par plusieurs developpeurs. Elle corrige les 
defauts du verrou en preferant gerer les eventuels conflits de modification plutot qu'en les 
empechant par une serialisation des modifications. 
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Tout developpeur desirant modifier une ressource peut en obtenir une copie en ecriture a 
tout moment de la part de l'outil de gestion de configuration. Une fois sa modification 
effectuee, celle-ci est soumise a l'outil de gestion de configuration. 

Deux cas de figure se presentent alors : 

• Si la version a partir de laquelle le developpeur a travaille est la meme que celle du 
referentiel, cette derniere est remplacee par la version modifiee. 

• Si la version du referentiel est plus recente que la version sur laquelle a travaille le 
developpeur, il y a conflit, et un processus de fusion des deux versions est lance. La 
version fusionnee remplace la version du referentiel. 

La figure 2.2 illustre la modification simultanee de la ressource R par deux developpeurs. 
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Figure 2.2 

Fonctionnement de la fusion 



Le processus de fusion (etape 4 sur la figure) declenche en cas de conflit est tres simple. 
II suffit de comparer la copie locale de R avec celle contenue dans le referentiel a l'aide 
d'outils rendant cette tache aisee et d' identifier les differences. Pour chaque difference, le 
developpeur peut choisir de la prendre ou non en compte afin d' obtenir in fine une 
version fusionnee de R destinee a etre stockee dans le referentiel. 

La figure 2.3 illustre l'assistant CVS d'Eclipse permettant de resoudre les conflits entre 
la copie locale d'une ressource et celle stockee dans le referentiel. 
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Figure 2.3 

L' assistant CVS de resolution des conflits dans Eclipse 

Plus complexe que la precedente en cas de conflit, cette strategie peut aussi paraitre plus 
laxiste et difficile a mettre en oeuvre dans la pratique. Cependant, la securite apportee par 
les verrous se revele tres souvent disproportionnee par rapport a la realite des projets, et 
la resolution des conflits est souvent moins consommatrice de temps. 



Gestion des branches 

Au-dela de la gestion des modifications des ressources stockees dans le referentiel de 
l'outil de gestion de configuration, il peut se reveler necessaire de creer des versions 
paralleles, ou branches, d'un meme projet, ou tronc. Les branches deviennent necessaires 
a partir du moment oil un projet doit suivre des evolutions independantes et incompatibles 
entre elles. 

Un exemple classique d'utilisation des branches est la gestion de deux versions d'un meme 
logiciel en parallele. L'une d'elles est la version du logiciel diffusee aux utilisateurs finals 
(appelee n) et 1' autre la prochaine version (appelee n + 1) en cours de developpement. 

La version n + 1 peut etre lancee peu de temps apres la diffusion aux utilisateurs de la 
version n. La version n + 1 part des ressources de la version n pour introduire des evolu- 
tions dans le logiciel. Pendant le temps de developpement de la n + 1 , la version n qui est 
diffusee aux utilisateurs peut etre aussi amenee a evoluer au fil d' operations de maintenance 
principalement correctives. 
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Les contraintes qui s'appliquent a ces deux versions sont differentes : 

• La version n se doit d'etre un reflet exact de ce qui est diffuse aux utilisateurs. Les 
operations de maintenance suivent un cycle court entre la realisation et la diffusion des 
correctifs. Entre chacune de ces operations, la consistance entre la branche n et ce qui 
est diffuse doit etre garantie. 

• La version n+ 1 etant en cours de developpement, elle compromet la capacite du logi- 
ciel a fonctionner correctement puisqu'elle introduit de nouveaux composants dans un 
etat plus ou moins avance de developpement et, bien sur, son propre lot de bogues, y 
compris des regressions. 

La figure 2.4 illustre les processus associes a la maintenance de la version n et aux evolutions 
de la versions + 1. 
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Figure 2.4 

Processus associes a la maintenance et aux evolutions 



Ces contraintes soulignent bien 1' importance de separer la gestion des evolutions de ces 
deux versions du logiciel a l'aide de branches. Concretement, la version n + 1 etant la 
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ligne principale de developpement de l'application, elle constitue le tronc. Pour rendre 
independantes les evolutions de n et n + 1 , il suffit de creer une branche pour n. Celle-ci 
est destinee a devenir une branche morte des lors que la version n + 1 devient la version 
courante et que la version n n'est plus supportee, comme illustre a la figure 2.5. 
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Figure 2.5 

Debranchement pour la maintenance 

Les outils de gestion de configuration permettent de gerer une veritable arborescence et 
non simplement deux branches, chaque branche pouvant elle-meme etre source d'autres 
branches, etc. 

Linteret des branches par rapport a une copie pure et simple des ressources reside dans la 
capacite des outils de gestion de configuration a les fusionner. 

Dans notre exemple, il est vraisemblable que les operations de maintenance corrective de 
la branche n doivent etre reportees dans le tronc de la version n + 1 . Plutot que de le faire 
manuellement, avec des risques d'erreur dans le report des corrections, il est preferable 
de se faire assister dans cette tache par l'outil de gestion de configuration. 

Si la ou les branches divergent trap, les conflits deviennent trop nombreux pour etre geres 
simplement. Dans notre exemple, il est des lors preferable d'effectuer des reports perio- 
diques de la branche vers le tronc (points de synchronisation), plutot que de le faire en 
une seule fois. 



Gestion des cliches 

Les outils de gestion de configuration offrent systematiquement une fonction permettant 
de prendre des cliches d'un projet, au meme titre que Ton prend un cliche d'un paysage 
avec un appareil photo. Cette fonction est particulierement utile pour tiger l'etat d'un projet 
et lui associer une etiquette, generalement un numero de version global pour 1' ensemble 
des ressources composant le logiciel. 
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II est interessant de prendre un cliche comprenant notamment tout le code source pour 
chaque version du logiciel qui sera diffusee aux utilisateurs. Ce cliche represente le logiciel 
dans un etat stable, puisqu'il est livre aux utilisateurs, et peut etre extrait a tout moment 
si necessaire. II definit aussi la racine commune entre la branche et le tronc. 

L'utilisation de cette fonction peut meme etre une obligation legale, 1' administration fiscale, 
par exemple, pouvant demander a tout moment les traitements informatiques associes a un 
exercice comptable. Sans la fonction cliche, il est tout sauf evident de determiner quelles 
etaient les versions de chaque ressource correspondant au logiciel en place a l'epoque. 

En effet, chaque ressource au sein d'un outil de gestion de configuration voit son numero 
de revision evoluer independamment des autres en fonction des evolutions qu'elle subit. 
II n'est done pas aise d'identifier quelle version de ressource correspond a quelle version 
globale du logiciel. Seule la fonction cliche permet d'associer facilement les versions des 
ressources a une version globale. Dans la terminologie de CVS, les versions specifiques 
a chaque ressource s'appellent des revisions alors que les etiquettes s'appellent des 
versions ou des tags. 

La figure 2.6 illustre la gestion des cliches au sein d'un gestionnaire de configuration. 
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Gestion de configuration dans le cadre du refactoring 

La gestion de configuration est un element important a prendre en compte dans tout 
refactoring. En fonction de l'importance du refactoring et du cycle de vie du logiciel, les 
strategies de gestion de configuration a adopter ne sont pas les memes. 

Si le refactoring est « chirurgical », avec peu de composants concernes, et ne concerne aucun 
composant sensible du logiciel, il peut etre pris en compte dans le cadre des operations de 
maintenance classique. Les resultats du refactoring sont en ce cas integres directement a 
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la branche destinee a la maintenance, si elle existe, ou au tronc. II faut simplement veiller 
a ce que les operations de refactoring soient rapides afin de ne pas bloquer une diffusion 
de correctif du fait de l'inconsistance du logiciel qu'elles peuvent entrainer pendant leur 
developpement. 

Si le refactoring est important, il devient un projet a part entiere. Idealement, il n'est pas 
mene en parallele avec des evolutions fonctionnelles et peut etre traite au niveau de l'outil 
de gestion de configuration comme une version n + 1. Dans le cas contraire, 1' opportunity 
de creer une branche specifique depend des eventuelles interactions negatives qu'il peut 
y avoir entre les operations de refactoring et les evolutions fonctionnelles. 

Dans le cas d'un debranchement, il est important d'operer regulierement des points de 
synchronisation entre le refactoring et les evolutions fonctionnelles ou les maintenances de 
facon a pouvoir gerer le plus facilement possible les conflits entre le tronc et la branche. Ces 
conflits peuvent etre par ailleurs limites grace a une bonne planification des operations de 
refactoring tenant compte des contraintes de la maintenance ou des evolutions fonctionnelles. 



La gestion de configuration avec CVS 

Dans le cadre de cet ouvrage, nous utilisons CVS comme outil de gestion de configuration. CVS est un 
logiciel Open Source tres repandu, notamment sur les systemes UNIX, sa plate-forme d'origine. Sa 
toute premiere version date de la fin des annees 80 et la premiere version utilisable en reseau du debut 
des annees 90. 

Disponible sur http://www.cvshome.org, CVS est l'outil de gestion de configuration le plus utilise par les 
projets Open Source. II est generalement offert en standard par la plupart des sites communautaires 
specialises dans I'hebergement de projets Open Source, comme SourceForge.net ou ObjectWeb. 
CVS utilise la strategie de la fusion pour gerer I'acces simultane aux ressources du referentiel. II est 
architecture en deux couches, une couche cliente et une couche serveur, de maniere a permettre le 
travail en equipe sans contrainte geographique. Le referentiel est centralise sur la couche serveur et 
peut etre accessible par Internet. La couche cliente peut prendre de multiples formes, depuis le client en 
mode ligne de commande jusqu'a I'interface Web. Dans cet ouvrage, nous utilisons la couche cliente 
integree en standard dans Eclipse. 

CVS est aussi disponible sur plate-forme Windows pour la partie cliente (utilisee par les developpeurs) 
comme pour la partie serveur (hebergeant le referentiel). Cependant, la partie serveur etant deve- 
loppee par une equipe distincte de celle de CVS UNIX, ces deux versions ne sont pas entierement 
compatibles entre elles. La version Windows est disponible sur http://www.cvsnt.org. Dans le cadre de 
cet ouvrage, nous utilisons un referentiel CVS UNIX heberge sur le site SourceForge.net. 



Gestion des tests et des anomalies 

Les tests ont pour objectif de detecter les cas ou le logiciel ne fait pas ce qu'il est suppose 
faire (conformite vis-a-vis des specifications) et les cas oil le logiciel effectue des operations 
qu'il n'est pas suppose effectuer. 

La gestion des tests est cruciale pour tout projet logiciel puisque le service rendu aux 
utilisateurs en depend. Elle Test tout particulierement pour le refactoring, car celui-ci 
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doit rester invisible de l'utilisateur final, hormis un gain de performance ou de fiabilite 
eventuel. 

De ce fait, les tests doivent etre menes de maniere rigoureuse afin de garantir au minimum 
le meme niveau de fonctionnalite et la meme qualite de service que le logiciel disponible 
pour les utilisateurs finals. 

Differents types de tests permettent de couvrir l'ensemble des besoins. Les sections suivantes 
decrivent les plus significatifs pour le refactoring. Avant de les decrire, il nous semble 
important de faire quelques remarques d'ordre general qu'il faut avoir a l'esprit afin de definir 
sa strategie de test : 

• Mieux vaut ne pas attendre l'achevement de la realisation du logiciel pour le tester 
serieusement. Corriger une erreur tot dans le projet coiite toujours moins cher que de la 
corriger tard. 

• Lors de la definition de vos differents cas de test, ne negligez pas ceux qui concernent 
les conditions inattendues ou invalides, car c'est grace a ces derniers que vous pourrez 
tester la fiabilite de votre logiciel. 

• Dans le cadre de tout logiciel, il est important de capitaliser les cas de test utilises, car 
c'est grace a eux que vous pourrez tester la non-regression du logiciel dans les versions 
suivantes. A chaque nouvelle version a tester, il est tentant de ne verifier que les parties 
modifiees. Malheureusement, rien ne garantit que les apports de la nouvelle version 
n'ont pas d'effets nefastes sur le reste du logiciel. 

• Malgre tous les efforts que vous consacrerez a definir et a effectuer des tests, gardez a 
l'esprit qu'ils garantissent une seule chose, la non-detection d'erreur, et non l'absence 
d' erreur. 

Les tests unitaires 

Les tests unitaires sont les tests ayant la granularite la plus fine dans la panoplie des tests 
logiciels. Comme leur nom l'indique, ils sont destines a tester les composants du logiciel 
de maniere unitaire, c'est-a-dire un par un et pris le plus independamment possible des 
autres. Lobjectif des tests unitaires est de verifier si un composant remplit correctement 
son contrat vis-a-vis de ses specifications. 

En fonction de la nature du composant (classe, page Web statique, page Web dynamique, 
etc.), les methodes de test unitaire sont manuelles ou programmatiques. En effet, certains 
composants de bas niveau ne peuvent etre testes directement que de maniere programma- 
tique, par exemple, en creant un programme faisant appel a leurs methodes. D'autres 
composants, comme ceux qui generent des images dynamiquement, sont difficilement 
testables de maniere programmatique, sauf a utiliser des algorithmes de reconnaissance 
de forme. Ce genre de methode peut n'etre guere justifiable economiquement par rapport 
a un test manuel. 

II est important de noter que les tests unitaires doivent etre executes dans un environne- 
ment specifique reinitialise a chaque nouvelle campagne de tests unitaires. En effet, leur 
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execution peut entrainer des effets de bord, comme un etat instable de la base de donnees. 
Par ailleurs, il faut pouvoir les reproduire le cas echeant, ce qui necessite un environne- 
ment de test stable. 

Automatisation des tests unitaires 

Les tests unitaires automatiques presentent les avantages suivants en comparaison des 
tests unitaires manuels : 

• lis formalisent sous forme de programmes 1' ensemble des tests unitaires, ce qui permet 
de mieux verifier leur pertinence et leur exhaustivite. 

• lis evitent de faire manuellement les tests unitaires fastidieux. Les tests repetitifs sont 
generalement d'excellents candidats a 1' automatisation. 

• lis apportent des gains de productivite importants s'ils sont souvent utilises, notamment 
si les tests manuels sont d'une longueur penalisante. 

• lis evitent les erreurs humaines dans 1' execution des tests. 

Le principal probleme des tests unitaires est d'ordre economique. En effet, tester la tota- 
lite des composants de maniere unitaire peut etre long et couteux. Par ailleurs, le choix 
entre methode manuelle et automatique quand les deux sont possibles peut avoir un 
impact non negligeable sur les delais et les couts. II est preferable de se concentrer sur les 
composants sensibles ou complexes en les testant de la maniere la plus stricte plutot que 
de pratiquer un saupoudrage peu productif. 

La mise en place de tests automatiques pour des composants subissant regulierement des 
modifications profondes n'est pas non plus judicieuse. Si, a chaque modification, les tests 
unitaires doivent etre reecrits, leur surcout par rapport a des tests unitaires manuels peut 
ne pas etre amorti sur plusieurs executions. D'autant que leur programmation est souvent 
plus longue qu'un test manuel, notamment pour les tests unitaires concernant les interfa- 
ces homme-machine. 

Certains composants sont difficiles a tester unitairement, car ils sont trap dependants 
d'autres composants, ce qui empeche une utilisation aisee au travers de tests unitaires. Dans 
ce cas, il peut etre plus efficace de les tester indirectement au travers de composants faisant 
appel a leur service. L analyse de couverture, que nous abordons plus loin dans ce chapitre, 
permet de verifier dans une certaine mesure que ces composants ont bien ete sollicites. 

Pour chaque test unitaire, il est important de definir judicieusement son contenu. Les 
tests doivent etre concus de maniere a generer un comportement anormal de la part du 
composant. Par exemple, si vous testez un composant effectuant une division a partir de 
deux parametres, il faut donner la valeur au denominateur dans un test pour valider la 
bonne gestion de la division par 0. 

Le framework de tests unitaires JUnit 

Les tests unitaires automatiques peuvent etre realises de maniere « primitive » sous forme 
de petits programmes manipulant le composant a tester. Cependant, ces programmes ont 
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besoin d'un certain nombre d'elements pour pouvoir etre traites aisement, comme une 
fonction permettant de generer un rapport d'execution ou encore la possibilite d'executer 
un ensemble de programmes de tests. 

Dans la mouvance de 1'eXtreme Programming, le framework JUnit a ete cree par Erich 
Gamma et Kent Beck pour fournir un cadre logiciel au developpement de tests unitaires 
pour le langage Java. 

L' implementation d'un test unitaire avec JUnit consiste a creer une classe cas de test, 
derivant de la classe TestCase de JUnit, contenant une serie de methodes testant differen- 
tes fonctionnalites d'une meme classe Java. Typiquement, il existe une methode de test 
pour chaque fonctionnalite de la classe a tester. Pour valider la bonne execution des tests, 
JUnit fournit un ensemble de methodes, appelees assertions, permettant de confronter le 
resultat d'un test avec le resultat attendu. 

Par exemple, si vous testez une methode effectuant une simple division, une assertion 
s'attend a ce que 4 divise par 2 produise 2. Si tel n'est pas le cas, le test unitaire echoue. 
Ces assertions permettent d'enregistrer les succes et les echecs pour les restituer in fine 
au developpeur. 

Chaque cas de test peut etre execute en utilisant un des executeurs de tests unitaires four- 
nis par JUnit. Ces executeurs sont en mesure de traiter de maniere efficace les resultats 
produits par les cas de test, en faisant apparaitre les succes, les echecs et les messages 
d'erreur associes a ces derniers. 

La figure 2.7 illustre l'executeur JUnit integre a Eclipse affichant un cas de test qui a 
echoue. 
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Les cas de test peuvent etre regroupes sous forme de suites de tests. Une telle suite est 
definie en creant une classe derivant de la classe TestSui te de JUnit regroupant les appels 
a plusieurs cas de test. Ainsi, 1' execution d'un grand nombre de cas de test est facilitee. 
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Les frameworks derives de JUnit 

JUnit fournit un framework de tests unitaires bien adapte aux classes Java. II a ete adapte 
pour supporter d'autres langages, comme NUnit pour .Net et Unit++ pour C++. 

D'autres frameworks derives ont ete crees pour tester d'autres composants que les objets 
issus des langages de programmation. II en est ainsi de StrutsTestCase, destine a tester les 
applications Web utilisant le framework Struts. 

Ces frameworks conservent la notion de TestCase et de TestSui te, ce qui leur permet de garder 
une compatibilite ascendante avec JUnit et done de beneficier de ses executeurs de test. 

Les tests unitaires dans le cadre du refactoring 

Dans le cadre du refactoring, les impacts sur les tests unitaires existants peuvent etre impor- 
tants du fait que la structure des classes peut etre modifiee. II faut done integrer le cout de 
l'adaptation des tests unitaires dans le projet. II est par ailleurs souhaitable d'encadrer les 
differentes operations de refactoring par des tests unitaires. Rappelons que ces operations 
ne doivent pas modifier le comportement de l'application vis-a-vis de l'utilisateur final. Les 
tests unitaires offrent une granularite suffisamment fine pour garantir le maintien du contrat 
entre les composants du logiciel et leurs specifications apres refactoring. 



Les tests unitaires avec JUnit et StrutsTestCase 

Dans le cadre de cet ouvrage, nous nous interessons a deux frameworks Open Source de tests 
unitaires complementaires, JUnit, qui fournit un socle pour tester les objets Java, et StrutsTestCase, pour 
tester les applications Web fondees sur Struts, ^utilisation de ces frameworks s'effectue au sein d'Eclipse 
afin de profiter de I'integration de JUnit offerte en standard par cet environnement de developpement. 
StrutsTestCase est un projet Open Source telechargeable sur le site Web SourceForge.net, a I'adresse 
http://strutstestcase.sourceforge.net/. 



Les tests fonctionnels 

Les tests fonctionnels sont destines a verifier que les fonctionnalites offertes aux utilisa- 
teurs finals sont conformes a leurs attentes. Les tests fonctionnels sont generalement 
lourds a mettre en oeuvre, surtout pour les nouveaux logiciels, pour lesquels tout est a 
construire. Les scenarios de tests sont definis pour une fonctionnalite precise afin de faciliter 
la communication entre testeurs et developpeurs en delimitant un perimetre precis. 

Les tests fonctionnels sont generalement formalises sous forme d'un plan de tests regrou- 
pant un ou plusieurs scenarios d' utilisation. Ces scenarios comprennent une ou plusieurs 
etapes elementaires d'interaction avec le logiciel et definissent pour chacune d'elles les 
preconditions a remplir avant l'execution de l'etape et les postconditions a respecter 
apres l'execution de l'etape. Generalement, les preconditions specifient l'etat dans lequel 
doit se trouver le logiciel pour permettre l'execution de l'etape et les postconditions le 
resultat attendu. 
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La figure 2.8 illustre la definition d'un test fonctionnel dans l'outil TestRunner s'integrant 
au gestionnaire d'anomalies Bugzilla. 
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Figure 2.8 

Definition d'un cas de test dans TestRunner 



Automatisation des tests fonctionnels 

A l'instar des tests unitaires, les tests fonctionnels peuvent etre automatises, sauf dans les 
cas ou la simple simulation d'un utilisateur reel est insuffisante. Lorsqu'ils concernent 
l'interface homme-machine, ils mettent en oeuvre des logiciels specifiques permettant 
d'enregistrer et de rejouer des scenarios d' utilisation. 
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L'enregistrement consiste a capturer les actions d'un utilisateur reel sur le logiciel a 
tester. Bien entendu, les actions effectuees par l'utilisateur suivent les etapes specifiers 
dans le scenario d'utilisation. Cet enregistrement produit un programme, ou script, inter- 
pretable par le moteur de rejeu, lequel est ainsi capable de simuler l'utilisateur reel du 
point de vue du logiciel. 

Le script est generalement modifiable afin de le rendre plus generique et de couvrir plus 
de cas de figure. Typiquement, ce type de generalisation consiste en la transformation des 
donnees saisies par l'utilisateur reel et stockees en « dur » par l'enregistreur en variables. 
II est alors possible de creer plusieurs jeux de donnees et d' avoir ainsi plusieurs variantes 
d'un meme scenario, ameliorant d'autant le niveau de couverture des tests. 

Tout comme les tests unitaires automatiques, les scenarios d'utilisation peuvent etre 
executes a volonte. II faut cependant veiller a ce que les modifications d'lHM soient 
correctement reportees dans les scripts. Si l'interface homme-machine est destinee a etre 
modifiee systematiquement d'une version a une autre, comme dans un site Web avec une 
activite editoriale importante, l'obsolescence des scripts peut rendre l'automatisation 
redhibitoire en comparaison des tests manuels. 

Meme assistee par l'enregistreur, la realisation des scripts reste une operation longue et 
demandant un certain niveau d'expertise pour etre rendue generique, et done perenne. Ce 
surcout non negligeable par rapport aux tests manuels doit etre amorti par une reutilisation 
sur plusieurs versions successives. 

Les tests fonctionnels dans le cadre du refactoring 

Pour le refactoring, ce type de test est utilise afin de verifier la non-regression du logiciel 
du point de vue de l'utilisateur. Cette verification est primordiale, car le resultat attendu 
doit etre transparent pour l'utilisateur, le refactoring ne devant avoir aucun impact de son 
point de vue, si ce n'est un gain eventuel en terme de stabilite et de performance, mais ce 
n'est pas la le but premier du refactoring. 

II est done important d'avoir un plan de test fonctionnel le plus complet possible pour les 
parties du logiciel impactees par le refactoring mais aussi pour les autres parties, du fait 
des effets de bord eventuellement induits par les resultats de l'operation. Ce plan de test 
doit bien entendu etre realise sur le logiciel avant son refactoring. 

Les tests de charge 

Les tests de charge sont proches des tests fonctionnels dans le sens ou ils reposent eux 
aussi sur des scenarios d'utilisation. Leur objectif est toutefois different, puisqu'il vise a 
stresser le logiciel afin de voir comment son comportement evolue en simulant un 
nombre variable d'utilisateurs le sollicitant. II ne s'agit done plus de verifier le respect 
des regies de gestion ou tout autre aspect strictement fonctionnel. 

Un logiciel fonctionnant parfaitement avec un seul utilisateur peut avoir un comportement 
totalement erratique des qu'il y en a plusieurs. Ce type de comportement peut avoir des sour- 
ces multiples, comme une mauvaise gestion des acces simultanes a une ressource partagee. 
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Automatisation des tests de charge 

Les tests de charge sont generalement automatises. II serait en effet peu rentable de mobiliser 
une armee de testeurs pour stresser le logiciel. 

Comme pour les tests fonctionnels, les scenarios de test sont le plus souvent obtenus 
grace a un enregistreur capturant les actions d'un utilisateur reel. Les scenarios, eventuel- 
lement adaptes manuellement, sont ensuite deployes sur un ou plusieurs injecteurs. Les 
injecteurs sont installes sur des machines et simulent un ou plusieurs utilisateurs selon 
une cadence predefinie (un injecteur peut simuler un nombre variable d'utilisateurs en 
fonction de la machine qui l'heberge). Pour chaque execution, des statistiques sont calculees 
arm de determiner la performance de l'application du point de vue de l'utilisateur simule. 

La figure 2.9 illustre les statistiques produites par l'outil de test de performance OpenSTA. 
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Figure 2.9 

Statistiques produites par OpenSTA 
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Pour une vision plus complete, la machine hebergeant le logiciel teste peut etre observee 
par plusieurs sondes logicielles permettant de capturer differents parametres quantitatifs 
lies au fonctionnement du logiciel, comme 1' utilisation du processeur, de la memoire, etc. 
Pour cela, il convient d'utiliser soit l'outil de test de charge qui fournit ses propres sondes, 
soit les outils de supervision fournis avec le systeme d'exploitation, comme illustre a la 
figure 2.10. 
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Figure 2.10 

Supervision des ressources materielles sous UNIX avec Vutilitaire top 



L' interpretation des resultats produits par les sondes demande une bonne connaissance 
des differents parametres influant sur la performance (logiciels, materiels et reseaux) et 
de leurs interactions. C'est pourquoi l'analyse de performance est generalement prise en 
charge par des experts techniques. 

Les tests de charge dans le cadre du refactoring 

Les tests de charge sont utiles de deux manieres differentes dans le cadre du refactoring : 

• En procedant a une analyse du comportement du logiciel en charge, il est possible de 
detecter d'eventuels goulets d'etranglement susceptibles d'etre resorbes par une operation 
de refactoring. 
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• Les tests de charge sont aussi un moyen de garantir que le refactoring n'a pas degrade 
les performances du logiciel. II suffit de definir des scenarios et de les lancer avant et 
apres le refactoring. 

L'analyse de couverture 

L' analyse de couverture est un complement necessaire a toute campagne de tests en ce 
qu'elle permet de visualiser si le code source de l'application est couvert par les tests. 
Elle identifie non seulement les zones non couvertes par les tests et contenant done 
potentiellement des anomalies, mais permet accessoirement d'identifier d'eventuels tests 
redondants. 

La figure 2.1 1 illustre le type de statistiques produites par l'outil d' analyse de couverture 
EMMA. Les pourcentages indiquent le taux de couverture a differents niveaux d'agregation 
(package, classe, methode, etc.). 
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Figure 2.11 

Statistiques de couverture fournies par EMMA 



Pour chaque classe (fichier source), les outils de couverture offrent generalement la 
possibilite de visualiser les lignes de code source effectivement couvertes par les tests, 
comme l'illustre la figure 2.12 (les lignes foncees correspondent a des instructions non 
couvertes). 
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Figure 2.12 

Detail de la couverture d'une classe analysee par EMMA 



Typologie des tests de couverture et limites 

II existe differents types d'analyse de couverture offrant une vision plus ou moins fine de 
la facon dont les tests couvrent les fonctionnalites du logiciel. 

La plus frequente est 1' analyse de couverture des instructions. Cette analyse indique pour 
chaque ligne de code d'une application si elle a ete ou non executee. Cette analyse a 
cependant le defaut de ne donner que tres peu d' information sur 1' execution des structu- 
res de controle telles que les conditions ou les boucles. Elle ne permet que de savoir si le 
bloc de code associe a une condition ou a une boucle a ete execute ou non. II est done 
impossible de determiner quels elements d'une condition complexe ont declenche 1' execution 
du bloc de code associe. 

Dans l'exemple de code suivant : 

I if (conditionl || condition2) { 
// Traitements 
} 
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une analyse de couverture se limitant aux instructions ne permet pas de savoir quelle 
condition a declenche les traitements. Or il est important de savoir si les deux conditions ont 
permis de declencher le bloc. Dans le cas contraire, l'une d'elles n'est pas utile puisqu'elle 
est necessairement fausse. 

De meme, pour une boucle, cette analyse ne permet pas de savoir combien de fois celle-ci 
a ete executee ou si sa condition de fin a ete atteinte. 

Dans l'exemple de code suivant : 

I while (condition) { 
// Traitements 
) 
une analyse de couverture limitee aux instructions signale si la boucle whi 1 e a ete declen- 
chee ou non mais ne permet pas de savoir combien de fois la boucle a ete executee. 

Des techniques d' analyse de couverture plus evoluees se concentrent sur les structures de 
controle. L' analyse de couverture des conditions permet de determiner pour chaque 
condition si elle a ete evaluee a vrai ou a faux. Plus sophistiquee, 1' analyse de couverture 
des chemins s' attache a verifier qu'une methode a ete executee de toutes les manieres 
possibles de son point d'entree a son point de sortie. Ce dernier type d'analyse est tres 
difficile a mettre en oeuvre du fait de l'explosion combinatoire des chemins en fonction 
des conditions contenues dans la methode. 

En conclusion, 1' analyse de couverture permet de savoir ce qui n'a pas ete couvert, mais 
en aucun cas si ce qui a ete couvert l'a ete totalement. 

L'analyse de couverture dans le cadre du refactoring 

L' analyse de couverture est un outil complementaire de la panoplie de tests a mettre en 
oeuvre pour valider le refactoring. Elle permet de verifier que les zones du logiciel impac- 
tees par le refactoring sont bien couvertes par des tests. Elle n'offre pas une garantie 
absolue d'exhaustivite des tests mais reduit significativement les risques. 



L'analyse de couverture avec EMMA 

Dans le cadre de cet ouvrage, nous utilisons I'outil d'analyse de couverture Open Source EMMA, dispo- 
nible sur http://emma.sourceforge.net. Cet outil analyse I'execution des programmes Java afin de 
generer in fine un ensemble de rapports sous differents formats (HTML, XML, etc.). II offre une vision 
de la couverture du code avec plusieurs niveaux d'agregation (projet, package, classe, methode, ligne 
de code). II propose en outre l'analyse de couverture des instructions, ce qui est largement suffisant 
pour nos besoins. 

Avec EMMA, I'instrumentation des programmes a analyser peut se faire de deux manieres, a froid ou a 
chaud. L'instrumentation consiste a modifier les classes compilees du programme pour y inserer des 
instructions supplementaires tragant I'execution de chaque ligne de code. L'instrumentation a froid 
s'effectue juste apres la compilation et a pour effet de modifier le bytecode de chaque classe. 
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Une fois I'instrumentation a froid effectuee, le programme peut etre lance normalement. Pour des 
raisons evidentes de performances, les classes instrumentees ne doivent pas etre utilisees en produc- 
tion, [^instrumentation a chaud permet d'effectuer le tragage sans modifier directement les classes 
compilees du programme. Par contre, cette instrumentation necessite I'utilisation d'un lanceur particu- 
lier pour executer le programme. Ce mode de fonctionnement est generalement incompatible avec les 
serveurs d'applications tels que Tomcat, WebSphere ou WebLogic, contrairement a I'instrumentation a 
froid, qui est completement transparente de leur point de vue. 



Gestion des anomalies 

Une strategie de tests efficace doit comprendre un bon outil de gestion des anomalies. 
Grace a celui-ci, la communication entre les testeurs et les developpeurs est plus efficace, 
car formalisee dans un processus de gestion des anomalies. 

Cycle de vie de la gestion des anomalies 

La gestion d'une anomalie suit le cycle de vie illustre a la figure 2.13 et repris en detail 
dans les sections suivantes. 
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Cycle de vie d'une anomalie 
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Detection 

La detection est l'etape la plus evidente : lors d'un test, une anomalie est detectee. Cette 
apparente simplicite ne doit pas masquer 1' importance de cette etape. Lors de la detection, 
le testeur collecte le maximum d' information sur les conditions dans lesquelles 1' anomalie 
est apparue, car c'est grace a ces informations que la correction sera efficace. 
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Declaration 



La declaration consiste a remplir une fiche d'anomalie geree par l'outil de gestion des 
anomalies. Afin de ne pas polluer la base des Aches d'anomalie, il est necessaire de verifier 
qu'une anomalie n'est pas deja declaree. 

La tiche d'anomalie est un formulaire comportant des questions ouvertes et fermees 
permettant de qualifier le plus clairement possible la nature de 1' anomalie et les conditions 
dans lesquelles elle est apparue. Si elle est apparue dans 1' execution d'un scenario de test 
formalise, il suffit de preciser a quelle etape elle a eu lieu. 

Cette fiche est primordiale dans la communication entre les testeurs et les developpeurs. 
Si une fiche n'est pas assez precise, les developpeurs ne sont pas en mesure de reproduire 
1' anomalie dans leur environnement et ne sont done pas en mesure de la corriger. lis 
peuvent la rejeter en la qualifiant de non reproductible ou d'insuffisante. 

Une fiche d'anomalie comporte generalement les informations suivantes : 

• Un identifiant, de maniere a assurer la tracabilite de 1' anomalie. 

• L auteur de la fiche. 

• Une description courte (ou titre) permettant de cerner rapidement la nature de 
1' anomalie. Cette description doit etre synthetique tout en refletant suffisamment la 
nature de l'anomalie. Une description du type « le logiciel ne fonctionne pas » n'est pas 
d'une grande aide. 

• Le logiciel et la version concernee. 

• La plate-forme technique utilisee (systeme d'exploitation, navigateur Web, etc.), certaines 
anomalies n'apparaissant que sur certaines plates-formes. 

• La categorie de 1' anomalie. Cette information est importante pour le chef de projet, car 
elle l'aide efficacement a affecter les anomalies, sous reserve que la categorisation soit 
pertinente. 

• La severite de l'anomalie. Cette indication donne une idee de la capacite du logiciel a 
repondre aux attentes des utilisateurs. Plusieurs niveaux de severite peuvent etre definis 
dans cet objectif, notamment les suivants : bloquante (le logiciel est rendu inutilisable 
par cette anomalie), majeure (l'anomalie empeche une fonctionnalite importante de 
fonctionner), normale, mineure (l'anomalie est genante mais n'empeche pas l'utilisation 
du logiciel en l'etat), etc. 

• La priorite a accorder a la correction de l'anomalie. 

• Les etapes a suivre pour reproduire l'anomalie. Ces etapes doivent se limiter a celles 
qui sont strictement necessaires pour la reproduction de l'anomalie. Plus les etapes a 
suivre sont nombreuses, plus la reproduction est longue, fastidieuse et sujette a erreur, 
et done a la non-reproduction de l'anomalie. 

• Le statut de l'anomalie. Au moment de la creation de la fiche, il est defini a « ouverte ». 
Les etapes suivantes dans le cycle de vie de la fiche vont conduire a modifier ce statut. 
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• Des pieces attachees, qui offrent la possibility de joindre tout element complementaire 
utile pour faciliter la reproduction ou la correction de l'anomalie. Les pieces jointes 
classiques sont des captures d'ecran montrant l'anomalie. 

• Le developpeur charge de la correction. Cette information est renseignee dans l'etape 
suivante, que nous decrivons ci-dessous. 

La figure 2.14 illustre une fiche d'anomalie telle que definie dans BugZilla, l'un des outils 
de gestion d'anomalies les plus connus dans le monde Open Source. 
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Bien entendu, cette liste n'est pas exhaustive, d'autant que la plupart des outils de gestion 
des anomalies du marche donnent la possibilite de modifier les fiches d'anomalie afin de 
les adapter au contexte de chaque projet. Par ailleurs, ces outils offrent souvent une fonc- 
tion d'historique tracant les evolutions subies par la fiche d'anomalie. 

Affectation 

Le chef de projet doit avoir une vision exhaustive des anomalies, notamment des anomalies 
ouvertes, c'est-a-dire non corrigees. II peut s'appuyer pour cela sur l'outil de requete fourni 
par l'outil de gestion des anomalies. La figure 2.15 illustre celui offert par BugZilla. 
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Figure 2.15 

Outil de requete de BugZilla 
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Comme il y a generalement plus d' anomalies que de developpeurs disponibles pour les 
corriger, le chef de projet utilise le contenu de la fiche pour repartir les charges de correc- 
tion, identifier le developpeur le plus competent dans ce contexte et affecter les priorites 
(via le champ priorite de la fiche). Cette affectation a pour resultat de faire apparaitre la 
fiche d'anomalie dans la liste des anomalies a corriger du developpeur selectionne, gene- 
ralement par ordre de priorite decroissant. 

Le chef de projet a la possibilite de ne pas affecter l'anomalie pour correction dans les 
cas suivants : 

• Correction differee : l'anomalie n'etant pas critique, sa correction est reportee a une 
date ulterieure d'un commun accord entre la maitrise d'ouvrage et la maitrise d'oeuvre. 

• Dupliqua : l'anomalie est deja declaree dans une autre fiche. 

Correction 

La correction est effectuee par le developpeur qui s'est vu affecter l'anomalie. La 
premiere etape de la correction consiste pour le developpeur a tenter de la reproduire 
dans son environnement. Plus les informations fournies par la fiche sont precises, plus 
cette tache est facile. Si les informations sont insuffisantes, le developpeur lui affecte le 
statut « besoin de plus d' information ». 

Par ailleurs, il est possible que l'anomalie signalee n'en soit pas une et qu'elle soit reje- 
tee. Par exemple, le comportement du logiciel signale comme anormal est cependant 
conforme aux specifications ou bien une erreur de manipulation de la part de l'utilisateur 
est survenue. 

Si l'anomalie est reproductible, cela signifie generalement que sa cause peut etre aise- 
ment delimitee. Si elle n'est pas reproductible, sa correction est beaucoup plus delicate 
puisque, par definition, le developpeur n'est pas en mesure de la reproduire dans son 
environnement de debogage. Le plus sou vent, l'anomalie se voit affecter le statut « non 
reproductible » en attendant de mieux la cerner pendant la suite des tests. 

Une fois l'anomalie reproduite et corrigee, le developpeur doit tester le logiciel modifie 
de maniere a verifier l'exactitude de la correction. Le developpeur peut en outre s'assurer 
que la correction n'a pas genere elle-meme d'autres anomalies. Une fois la correction 
verifiee par le developpeur, celui-ci donne a l'anomalie le statut « corrigee ». 

Validation et fermeture 

La validation de la correction est generalement effectuee par le testeur ayant declare 
l'anomalie correspondante. Cette validation est aussi l'occasion de verifier si la correction 
n'a pas eu d'effets de bord nefastes qui n'auraient pas ete detectes par le developpeur. 

Une fois la correction validee par le testeur, celui-ci effectue la fermeture de la fiche 
d'anomalie. Si l'anomalie reapparait, la fiche est rouverte, plutot que de creer un dupliqua 
rompant la tracabilite. 
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Gestion des anomalies dans le cadre du refactoring 

Une gestion efficace des anomalies est un facteur de succes d'un projet de refactoring. 
Le traitement de ces dernieres doit en effet etre mene avec le plus grand soin de maniere 
a fournir une nouvelle version du logiciel au moins aussi stable que la precedente. 

La base des anomalies est en outre une source d'information interessante pour identifier 
les parties du logiciel candidates au refactoring. Elle permet d' avoir une tracabilite des 
problemes et des corrections associees, a la condition que les developpeurs documentent 
correctement leurs actions correctives. 



Conclusion 



Grace a 1' infrastructure presentee dans ce chapitre, le refactoring peut s'effectuer en toute 
serenite. 

Comme nous le verrons au chapitre suivant, cette infrastructure peut fournir des renseigne- 
ments precieux pour analyser les faiblesses du logiciel et detecter des candidats potentiels 
au refactoring. 



3 



L'analyse du logiciel 



L'analyse du logiciel est une phase du processus de refactoring, dont Tissue permet de decider 
quelles parties du logiciel seront refondues. L'objectif de ce chapitre est de decrire les 
differents types d' analyses possibles ainsi que les problematiques associees. 

Nous n'avons pas a notre disposition de baguette de sourcier pour nous indiquer quels 
composants doivent etre refondus. Cependant, des analyses permettent de soumettre le 
logiciel a la critique en posant des questions sur sa qualite, sa complexite et ses perfor- 
mances. A Tissue de cette phase d' analyse, les resultats obtenus permettent de fonder nos 
decisions quant aux composants a refondre. 

Ce chapitre aborde les deux grandes categories d' analyse applicables au logiciel : 

• L'analyse quantitative, c'est-a-dire la mesure de quantites permettant de connaitre 
certaines proprietes du logiciel. 

• L'analyse qualitative, qui confronte le logiciel a T experience et aux bonnes pratiques 
pour juger de sa qualite. 



L'analyse quantitative du logiciel 

L analyse quantitative du logiciel, ou metrologie, est un domaine en phase de maturation, 
qui n'offre pas encore les memes services que d'autres domaines d' application, comme 
la mecanique ou la chimie. 

Cependant, aussi imparfaite soit-elle, elle fournit au chef de projet un certain nombre 
d'indicateurs sur le logiciel dont il a la charge. Ces indicateurs pointent du doigt d'even- 
tuelles inefficiences dans le logiciel, dont Texistence reelle doit etre verifiee en effectuant 
une revue de code (voir la section dediee d l'analyse qualitative). Comme nous le verrons, 
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les fondements de ces indicateurs sont tres souvent empiriques. lis sont done parfois 
generateurs de fausses alarmes, tandis que des zones a refondre peuvent leur echapper. 

L' analyse quantitative du logiciel pour le refactoring repose sur plusieurs indicateurs, que 
nous pouvons regrouper de la maniere suivante : 

• mesures des dimensions du logiciel ; 

• mesures des risques ; 

• mesures de la coherence ; 

• mesures de la qualite. 

Avant d'aborder ces differentes categories, il nous semble utile de nous attarder sur les 
problematiques des mesures et sur leur interpretation dans le domaine logiciel. 

La metrologie 

« Si vous pouvez mesurer ce dont vous parlez et V exprimer par un nombre, alors vous 
connaissez quelque chose de votre sujet. Si vous ne le pouvez, votre connaissance est 
d'une bien pauvre espece et bien incertaine. » Lord Kelvin 

La metrologie, ou science de la mesure, peut etre definie comme l'ensemble des techniques 
et savoir-faire qui permettent d'effectuer des mesures et d' avoir une confiance suffisante 
dans leurs resultats. La mesure est l'outil de comparaison et d' appreciation des objets par 
excellence. 

La notion de mesure 

La capacite a synthetiser les proprietes d'un objet sous forme numerique est a la base de 
toute science. Beaucoup de concepts classiques en metrologie ont leur origine dans la 
physique et sont appliques avec succes dans d'autres domaines, comme la technologie, 
la gestion ou l'economie. 

Une mesure est une grandeur numerique, ou quantite, generalement exprimee sous la 
forme d'un multiple d'une unite. Pour etre sujette a mesurage, la propriete d'un objet doit 
pouvoir etre determinee quantitativement. Une propriete est une quantite si elle permet 
un tri lineaire des objets selon cette propriete. En d'autres termes, une propriete p est une 
quantite si Ton peut dire que deux objets possedant p sont egaux ou qu'un objet est 
« inferieur » a un autre par rapport a p. Cette obligation elimine beaucoup de relations 
taxonomiques du perimetre de 1' analyse quantitative. 

Les mesures peuvent remplir les differents roles suivants : 

• Role evaluatif, consistant a decrire l'objet de la mesure. 

• Role verificatif, consistant a verifier que l'objet de la mesure est conforme a ce qui est 
attendu. 

• Role predictif, consistant a predire a partir du mesurage revolution future de l'objet. 
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Les mesures sont soit internes, soit extemes, c'est-a-dire qu'elles peuvent etre effectuees 
en observant l'interieur de l'objet d'etude, le code source, par exemple, ou l'exterieur, comme 
ses performances. 

La notion d'unite et de reference 

Une unite est une grandeur finie prise comme terme de comparaison avec des grandeurs de 
meme espece. Elle peut etre materialisee sous la forme d'un etalon servant de reference a 
toutes les mesures fondees sur cette unite. 



L'exemple du metre 

Un excellent exemple demontrant I'importance des unites de mesure est le metre. Avant sa definition au 
xvm e siecle, il n'y avait pas d'unite de mesure universelle de la longueur. Beaucoup des unites exis- 
tantes s'appuyaient sur une reference au corps humain (pied, pouce, etc.) et variaient fortement d'une 
region a une autre. Cette absence de reference universelle etait evidemment dommageable des points 
de vue scientifique et economique. 
En France, le 26 mars 1791 , la Constituante decrete : 

« Considerant que, pour parvenir a etablir I'uniformite des poids et mesures, il est necessaire de fixer 
une unite de mesure naturelle et invariable et que le seul moyen d'etendre cette uniformite aux nations 
etrangeres et de les engager a convenir d'un systeme de mesures est de choisir une unite qui ne 
renferme rien d'arbitraire ni de particulier a la situation d'aucun peuple sur le globe {...] adopte la gran- 
deur du quart du meridien terrestre pour base du nouveau systeme de mesures ; ies operations neces- 
saires pour determiner cette base, notamment la mesure d'un arc de meridien depuis Dunkerque 
jusqu'a Barcelone seront incessamment executees. » 

Ainsi, la dix millionieme partie de cet arc devient I'unite de longueur, le metre. Le systeme est decimal. 
La 17 e conference generale des poids et mesures choisit en 1983 une nouvelle definition du metre, 
offrant une nette amelioration de sa precision. II s'agit de la longueur du trajet parcouru dans le vide par 
la lumiere pendant 1/299 792 458 e de seconde. La realisation du metre, I'etalon, peut atteindre grace a 
cette definition une exactitude relative de 10~ 10 ou 10~ 11 . 

Rendu obligatoire en France a partir de 1840, le systeme metrique decimal est maintenant utilise par 
plus de cent trente pays et est integre au systeme international d'unites sous la responsabilite du 
Bureau international des poids et mesures. 



Les unites sont des instruments fondamentaux pour la comparaison des objets mesures. 
lis servent de reference commune, et plus ils sont repandus, plus ils sont efficaces. Par 
ailleurs, leur definition, comme pour le metre, doit etre effectuee avec une grande precision 
afin de rendre les comparaisons les plus fiables possible. 

L' absence de consensus sur une unite genere de grandes difficultes. On pense immediate- 
ment au systeme de mesures anglo-saxon et aux problemes poses par sa conversion dans 
le systeme metrique. 

Au-dela de la notion d'unite, il est important d' avoir des references. Une mesure sans 
element de comparaison est rarement utile pour juger des qualites de l'objet mesure. 
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Dans le cadre du logiciel, dire qu'un outil de conversion de monnaie contient mille lignes 
de code ne donne pas beaucoup d'indication sur les qualites de ce logiciel. II faut le comparer 
a un logiciel de meme type pour pouvoir donner du sens a la mesure. 

Le processus de mesurage 

Le mesurage est le processus par lequel des nombres sont assignes aux proprietes d'objets 
du monde reel de maniere a les decrire a partir de regies clairement definies. 

Ce processus comporte les quatre etapes fondamentales suivantes : 

1 . Definition des objectifs du mesurage. 

2. Definition de la methode de mesurage. 

3. Application de la methode de mesurage. 

4. Analyse des resultats du mesurage. 

Definition des objectifs du mesurage 

Avant de se lancer dans un mesurage, il est primordial de definir son objectif, c'est-a-dire 
1' information que nous desirons tirer de ses resultats. Un objectif trop large, comme de 
savoir si le code source d'un logiciel est de bonne qualite, ne saurait etre couvert par une 
seule methode de mesure. 

Definition de la methode de mesurage 

Cette etape permet de definir le plus precisement possible quelle propriete va etre mesuree 
et par quel moyen. Le choix de la propriete a mesurer est important, car cette propriete 
doit donner une representation numerique la plus exploitable possible en vue des objectifs 
definis a l'etape precedente. 

Si nous prenons comme exemple la ligne de code source comme propriete a mesurer, sa 
definition precise pose quelques difficultes. Les lignes blanches (vides), les lignes de 
commentaires ou les delimiteurs de blocs de code (les accolades en Java) doivent-ils etre 
comptes ? En fonction des reponses apportees a ces questions, la methode de mesure sera 
legerement differente. 

Une fois la propriete definie, il faut preciser les moyens a mettre en ceuvre pour la mesurer 
et s'assurer qu'ils permettent de la capturer correctement. II est done important de bien 
connaitre ce qui est mesure et comment le mesurage est effectue pour pouvoir exploiter 
efficacement le mesurage. 

Application de la methode de mesurage 

Une fois la methode de mesurage definie, il faut l'appliquer. 

Une etape prealable avant d'effectuer le mesurage reel est de verifier et de calibrer les 
instruments de mesure utilises pour le mesurage a partir d'exemples bien maitrises. Nous 
nous assurons de la sorte de 1' exactitude des resultats fournis par les instruments de mesure. 
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Par exemple, si nous effectuons des mesures de performances d'un logiciel de type appli- 
cation Web, il est souhaitable de tester les instruments de mesure sur une page Web vide. 
La coherence des resultats obtenus peut ainsi etre facilement verifiee et les eventuels 
problemes (reseau, serveur, etc.) corriges. II faut s'assurer par ailleurs que ces verifica- 
tions sont reproductibles, en prenant en compte un certain niveau d'erreur, qui caracterise 
le degre d'incertitude de toute mesure. II est done important d'effectuer les mesures dans 
un environnement le plus stable possible afin de ne pas fausser les resultats de 1' application 
de la methode sur l'objet reel a mesurer. 

Certains instruments de mesure peuvent avoir un effet direct sur la propriete observee et 
nuire a 1' interpretation si cet effet n'est pas pris en compte. Par exemple, les sondes 
permettant d'observer le taux d'utilisation du processeur d'un serveur consomment 
elles-memes les ressources du processeur. La connaissance de ces effets permet de calibrer 
1' instrument de mesure de maniere a produire des resultats les plus proches possible de 
la realite. 

Une fois les instruments de mesure verifies et calibres, la methode de mesurage peut etre 
appliquee sur l'objet a etudier. Les resultats obtenus doivent etre verifies en terme de 
coherence afin de detecter un eventuel dereglement des instruments de mesure ou une 
instabilite de 1' environnement faussant les resultats. Pour cela, les resultats obtenus a 
partir des exemples sont precieux. 

Analyse des resultats du mesurage 

L'analyse des resultats consiste a confronter les mesures obtenues a des references afin 
de tirer de l'information sur la propriete de l'objet observe. En l'absence de reference, les 
mesures ne sont que d'une faible utilite. 

Les references peuvent avoir differentes origines : standards industriels, meilleures pratiques 
issues d'etudes empiriques, valeurs optimales issues d'etudes scientifiques, etc. 

II est important de conserver l'historique des mesures, car celui-ci peut aussi servir de 
reference. C'est particulierement vrai dans le cadre du refactoring puisque nous nous 
interessons particulierement aux evolutions du logiciel qui peuvent etre caracterisees par 
les evolutions des mesures. 

La metrologie logicielle 

La metrologie logicielle est encore a l'etat embryonnaire, et les mesures que nous allons 
presenter dans les sections suivantes sont pour beaucoup insatisfaisantes pour juger de la 
qualite d'un logiciel. Cela s'explique par la jeunesse du domaine — les mesures physi- 
ques telles que nous les connaissons ont quelque deux cents ans derriere elles — et par 
ses specificites, qui ne lui permettent pas de se reposer sur les fondements de la metrolo- 
gie telle qu'utilisee en physique ou en chimie. 

La notion d' unite de mesure, fondamentale en metrologie, est tres peu formalisee dans le 
domaine logiciel, la ligne de code pouvant recouvrir differentes realites, comme nous 
l'avons vu. Les references de comparaison sont le plus souvent empiriques et peu 
nombreuses. Les evolutions technologiques ne facilitent pas la tache puisque, pour 
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chaque nouvelle technologie, il faut de nouvelles references. Par exemple, la notion de 
performance a ete completement bouleversee par 1' augmentation de puissance des 
microprocesseurs et les architectures paralleles. 

En conclusion, les mesures logicielles, aussi appelees metriques, sont loin d'avoir une 
fiabilite suffisante pour que des choix puissent etre fondes uniquement sur leurs resultats. 
De notre point de vue, les mesures logicielles sont utiles en depit de leurs faiblesses dans 
la mesure ou elles peuvent remonter des points d' attention, qu'il conviendra de verifier 
par une revue de code. Bien entendu, ces points d'attention ne sont pas d'une fiabilite 
absolue et risquent de generer de fausses alertes. Par ailleurs, les metriques ne permettent 
pas de detecter tous les problemes. 

Les mesures des dimensions du logiciel 

Les dimensions du logiciel sont les mesures parmi les plus simples a obtenir, meme si, 
comme pour beaucoup de mesures logicielles, les dimensions varient d'une technologie 
a une autre. 

Les dimensions d'un logiciel developpe a l'aide d'un langage oriente objet ne sont pas 
tout a fait les memes que celles d'un logiciel developpe a l'aide d'un langage procedural, 
la notion d'objet faisant apparaitre de nouvelles dimensions. De surcroit, de plus en plus 
de logiciels reposent sur plusieurs technologies, par exemple, les applications Web avec 
JavaScript, XML, XSL, etc., qui apportent chacune leurs propres dimensions. 

Les unites utilisees pour ces differentes dimensions n'ont pas le meme « poids » d'une 
technologie a 1' autre. Par exemple, une ligne de code source ecrite dans un langage de 
quatrieme generation (L4G) a beaucoup plus de « puissance » qu'une ligne de code 
source en assembleur. Une meme fonctionnalite est implemented en plus de lignes de 
code source dans le second cas que dans le premier, par exemple. 

II est done primordial de bien savoir ce que Ton mesure et comment on le mesure pour 
pouvoir exploiter efficacement les mesures de dimensions. 

Les dimensions globales 

Les dimensions globales s'interessent au logiciel dans son ensemble et offrent une 
vision macroscopique. Du fait de leur portee tres generale, ces dimensions ne sont pas 
de tres bons indicateurs pour detecter les zones du logiciel a inclure dans le refac- 
toring, sauf lorsqu' elles prennent des valeurs extremes ou sans rapport avec la nature 
du logiciel. 

Cependant, en historisant les dimensions d'une version a 1' autre du logiciel et en les 
comparant avec les evolutions correspondantes, il est possible de detecter certains pheno- 
menes macroscopiques denotant une erosion de 1' architecture du logiciel. C'est notam- 
ment le cas de la croissance inexplicable du nombre de lignes de code du logiciel a la 
suite d'une evolution mineure. 
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Le nombre de lignes de code source 

Le comptage des lignes de code source est la dimension la plus simple pour mesurer un 
logiciel. Comme nous l'avons deja indique, cette mesure pose un certain nombre de 
problemes : 

• Qu'est-ce qu'une ligne de code source ? 

• Quelle est la puissance d'une ligne de code source ? 

• Comment compter les lignes dans un logiciel integrant differentes technologies ? 

A ces trois questions, il n'y a malheureusement pas de reponse unique. Le comptage des 
lignes de code source n'est done pas une mesure universelle, a la difference des mesures 
physiques du systeme international. 

Les reponses a ces questions conditionnent cependant 1' interpretation du mesurage et 
varient d'un contexte technologique a un autre. 

Au niveau de l'ensemble du logiciel — combien de lignes de code source comprend le 
logiciel ? — , cette metrique n'est quasiment pas utilisable pour detecter des cibles poten- 
tielles au refactoring. Par contre, si nous nous interessons au nombre de lignes de certai- 
nes parties bien delimitees, une classe Java, par exemple, nous pouvons detecter d'even- 
tuels problemes. La mesure en elle-meme ne suffit toutefois pas, et il est necessaire 
d' avoir une reference. 

Par exemple, dans le cadre de 1' implementation d'un algorithme bien connu, comme un 
tri, nous pouvons determiner si le nombre de lignes de code source est coherent par 
rapport a la complexite de 1' algorithme. 

Les mesures historisees couplees aux evolutions du logiciel constituent aussi de bonnes 
references pour 1' interpretation de cette metrique. Par exemple, une classe Java ayant 
fortement augmente en nombre de lignes de code sans correlation evidente avec les 
evolutions du logiciel peut etre devenue une classe « poubelle » et necessiter une refonte. 

Le nombre de packages 

Le nombre de packages est un indicateur du regroupement des composants du logiciel en 
des entites organisationnelles. Les packages ayant une semantique importante et non 
quantifiable, cet indicateur n'est pas d'une grande aide pour savoir si le regroupement est 
pertinent ou non. 

Nous utilisons done cette metrique plutot pour detecter des valeurs extremes (petites ou 
grandes) injustifiables du point de vue de la nature du logiciel, comme un package unique 
pour l'ensemble des classes d'un logiciel de traitement de texte. 

Nombre de classes et d'interfaces 

A l'instar du nombre de packages, le nombre de classes et d'interfaces est un indicateur 
trap synthetique pour permettre de juger reellement de la pertinence des classes et inter- 
faces comptees. 
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En comptant les classes et interfaces pour un domaine fonctionnel particulier, il est nean- 
moins possible d'estimer si ce nombre est coherent par rapport a la richesse du domaine 
en question. Cela suppose evidemment que nous puissions les rattacher facilement a ce 
domaine, grace a une correspondance entre le package contenant les classes et interfaces 
comptees et le domaine fonctionnel, par exemple. 

Nous pouvons aussi comparer la difference entre les classes du logiciel et celles ayant ete 
modelisees lors des phases de conception successives. Une forte deviation peut indiquer 
soit une mauvaise synchronisation entre la conception et la realisation, soit 1' existence de 
classes developpees de maniere opportuniste et non optimale. 

Les dimensions d'une classe ou d'une interface 

Les dimensions associees a une classe ou a une interface sont principalement utilisees 
comme bases pour les mesures de risques que nous abordons plus loin dans ce chapitre. 

A l'instar des metriques precedentes, ces mesures sont souvent trop synthetiques pour 
evaluer la pertinence des elements comptes en dehors de la recherche des valeurs extremes 
ou incoherentes par rapport a la complexite fonctionnelle correspondante. 

Ces dimensions sont au nombre de quatre : 

• Nombre de methodes. 

• Nombre de methodes surchargees, c'est-a-dire heritees de la classe mere et redefinies 
dans la classe fille. 

• Nombre d'attributs. 

• Nombre de descendants directs/indirects. 

Du point de vue de la conception orientee objet, il est important de regarder attentivement 
le nombre de methodes surchargees et le nombre de descendants. Un nombre important de 
methodes surchargees peut indiquer une mauvaise utilisation de l'heritage. Un nombre de 
descendants important fait de la classe ancetre un point sensible du logiciel, et une modifi- 
cation de celle-ci peut avoir des effets de bord tres importants sur ses descendants. 

Les mesures historisees sont sensibles au renommage des classes. II est important de tracer 
ces modifications afin de pouvoir tracer revolution des metriques d'une classe ou 
d'une interface. 



Le plug-in Eclipse Metrics 

Dans le cadre de cet ouvrage, nous utilisons le plug-in Eclipse Metrics, disponible sur http:// 
metrics.sourceforge.net, pour calculer les differentes metriques abordees dans ce chapitre, a I'exception des 
metriques concernant la qualite du logiciel. 

Par rapport a d'autres outils du meme genre disponibles sous Eclipse, ce plug-in Open Source a pour 
particularite d'integrer un analyseur de dependances cycliques (voir la section de ce chapitre consacree 
a /'analyse qualitative). 
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Les mesures des risques 



Les mesures de la complexite sont efficaces pour detecter les cibles potentielles du refac- 
toring. Elles doivent cependant etre utilisees avec precaution, car elles sont sujettes a une 
forte incertitude. D'une part, ces mesures peuvent generer regulierement de fausses alertes 
et doivent done etre completees par une revue de code pour valider leur resultat. D' autre 
part, elles se revelent incapables de detecter certaines sources de complexite. 

II est tentant pour un chef de projet d'utiliser ces mesures pour controler la qualite de la 
production des developpeurs. Comme ceux-ci connaissent la facon dont ces mesures de 
complexite sont calculees, ils peuvent contourner les instruments de mesure, ce qui se 
revele contre-productif. Nous en donnons un exemple plus loin dans ce chapitre. 

La complexite cyclomatique 

La complexite cyclomatique est une mesure de la complexite tres repandue introduite par 
Thomas McCabe en 1976. Cette mesure fournit un nombre unique representant le 
nombre de chemins lineairement independants dans un programme. Cela donne une idee 
de l'effort a fournir pour tester le programme. 

Cette mesure a ete concue de maniere a etre la plus independante possible des langages 
auxquels elle est appliquee. Elle facilite de la sorte la construction de references pour 
estimer la complexite du logiciel etudie. 

Plusieurs etudes ont montre une correlation entre la complexite cyclomatique d'un 
programme et la frequence des erreurs en son sein. Une complexite cyclomatique basse 
semble contribuer a la creation de programmes de meilleure qualite. 

Le SEI (Software Engineering Institute) de l'universite Carnegie Mellon propose une 
table (voir tableau 3.1) pour estimer le risque associe a un programme a partir de sa 
complexite cyclomatique. 

Tableau 3.1 Niveau de risque associe a la complexite cyclomatique 



Complexite cyclomatique 


Niveau de risque 


1-10 


Programme simple, sans veritable risque 


11-20 


Programme moderement complexe et risque 


21-50 


Programme complexe et hautement risque 


>50 

I 


Programme non testable et extremement risque 



Le calcul de la complexite cyclomatique repose sur une representation du programme a 
mesurer sous forme de graphe. C'est grace a cette representation que le calcul de la 
complexite cyclomatique peut etre independant des langages de programmation. 

De maniere tres schematique, les instructions representent les noeuds, et leurs sequences 
possibles les arcs. Les instructions de type structures de controle (boucles, conditions) 
ont plusieurs arcs tandis que les autres instructions ne peuvent avoir au maximum qu'un 
arc entrant et un arc sortant. 
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A partir du graphe representant le programme, la complexite cyclomatique (CC) se 
calcule de la maniere suivante : 

CC=E-N+p 

ou E represente le nombre d'arcs du graphe et N le nombre de noeuds du graphe. Le 
nombre p represente la somme des points d'entree et de sortie dans le programme. 

Les trois exemples simples illustres aux figures 3.1 a 3.3 illustrent les representations de 
programmes sous forme de graphes, avec le calcul de la complexite cyclomatique corres- 
pondante. 



Graphe correspondant 



Code source Java 



System .out.printlnf'Calul de la division de 4 par 
2"); 

int resultat = 4/2; 

System. out. printlnf'Resultat : "+resultat); 



-"£> 



-0 

■© 



Figure 3.1 

Graphe d'un programme sans structure de controle 



Ce graphe comporte trois nceuds, un par instruction (la correspondance est donnee par les 
traits en pointilles), deux arcs (les fleches), un point d'entree et un point de sortie. La 
complexite cyclomatique de ce programme est la plus faible possible, c'est-a-dire 1 (2 - 3 + 2). 



Graphe correspondant 



Code source Java 



System .out.println("Calul de la division de 4 par 
2"); 

if (d!=0) { 

int resultat = 4 / d; 

System .out.println ("Resultat : "+resultat)|- 

} else { 

System .out.println (Tentative de division par 

0"); 

} 
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Figure 3.2 

Graphe d'un programme avec une structure de controle « si... alors... sinon » 
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Ce graphe comporte cinq noeuds relies par quatre arcs. Le programme possede un point 
d'entree et deux points de sorties (le bloc « si » et le bloc « sinon »). Sa complexite 
cyclomatique est de 2 (4 - 5 + 3). 



Graphe correspondant 



Code source Java 



System. out. println("Calul de la division de 4 par 
d"); 

while (d>0) { 

int resultat = 4/ d; 

System .out.println("Resultat : "+resultat)|- 
d--; 

} 
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Figure 3.3 

Graphe d'un programme avec une boucle « tant que... » 

Ce graphe possede quatre noeuds relies par quatre arcs (les boucles sont representees par 
un arc allant du noeud de la derniere instruction de la boucle jusqu'au noeud representant 
sa condition), un seul point d'entree et un seul point de sortie. Le programme a done une 
complexite de 2 (4 - 4 + 2). 

Dans le monde oriente objet, la complexite cyclomatique est generalement calculee pour 
chaque methode d'une classe. 

Pour avoir une idee de la classe dans son ensemble, il est possible de calculer une complexite 
cyclomatique moyenne et un ecart type. 

Un probleme de complexite cyclomatique peut etre aisement corrige par un developpeur. 
II lui suffit de casser la methode en plusieurs sous-methodes, de maniere a repartir les 
structures de controle sur celles-ci et a reduire en consequence la complexite cyclomatique 
de la methode originelle. Cependant, cette facon de faire est rarement la bonne et une 
re-conception est preferable. II est done important de ne pas utiliser ce type de mesure 
comme le ferait un Big Brother, car cela inciterait les developpeurs a brouiller les pistes 
plutot qu'a ameliorer le code du logiciel. 



La profondeur du graphe d'heritage 

La profondeur du graphe d'heritage est une mesure effectuee a partir d'une classe 
donnee. Elle determine la distance entre la classe observee et son ancetre le plus eloigne. 

La figure 3.4 illustre un exemple de graphe d'heritage. 
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Figure 3.4 

Graphe d 'heritage 



D'apres ce graphe d'heritage, la classe Personne physique a une profondeur d'heritage de 
1, car elle herite directe merit de son ancetre le plus eloigne, en 1' occurrence Personne. La 
classe SARL a une profondeur d'heritage de 2, car elle herite de son ancetre le plus lointain 
(Personne) via son ancetre direct Personne morale. 

Dans le cadre du langage Java, la profondeur d'heritage est generalement calculee a 
partir de la classe java.lang. Object, qui est Pancetre commun de toutes les classes Java. 
Cela a pour consequence que pourtoute classe Java, hormis java.lang. Object, la profondeur 
du graphe d'heritage vaut au moins 1. 

La profondeur du graphe d'heritage est une mesure importante en ce qu'elle permet de 
determiner pour chaque classe le poids de son heritage. Dans le paradigme oriente objet, 
P heritage est une notion tres forte, du point de vue tant semantique — on ne fait pas heri- 
ter une classe Chaise de la classe Personne — que technique (heritage des proprietes, ou 
attributs, et du comportement, ou methodes). 

Les graphes d'heritage tres profonds sont souvent contraignants et creent des phenomenes 
de degenerescence, les descendants n'ayant plus aucun rapport avec les ancetres. Cela 
entraine des rigidites inutiles et rend la conception du logiciel moins claire, et done 
moins maintenable. 



Le couplage 

Le couplage s'interesse au nombre de relations qu'entretient une entite vis-a-vis de 
l'exterieur. Cette entite peut etre un package, une classe, etc. 

Les relations sont de deux types : 

• De l'exterieur vers P entite observee (n classes utilisent la classe 0) ; nous parlons de 
couplage afferent. 
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• De 1'entite observee vers l'exterieur (la classe utilise m classes) ; nous parlons de 
couplage efferent. 

La figure 3.5 illustre la notion de couplage (le sens de la fleche va de l'utilisateur a l'utilise) : 
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Classes efferentes 



Figure 3.5 

Les deux types de couplage 



Dans cette figure, la classe a un couplage afferent de 3 et un couplage efferent de 2. 

La notion de couplage afferent est importante dans le cadre du refactoring, car elle 
permet d'associer un risque a la modification d'une entite. Plus une entite a un couplage 
afferent fort, plus sa modification risque d' avoir des effets de bord sur les entites utilisant 
ses services. 

La notion de couplage efferent permet d'associer un risque lie aux modifications de 
l'environnement de l'entite etudiee. Plus celui-ci est fort, plus l'entite etudiee depend de 
tiers pour remplir son service, ce qui augmente les risques d'effets de bord induits par les 
modifications de ces entites tierces. 



La profondeur d'imbrication des blocs de code 

La profondeur d'imbrication des blocs de code est une metrique determinee pour chaque 
methode. Elle est calculee tres simplement en determinant les niveaux d'imbrication des 
structures de controle au sein de la methode. 

Par exemple, la methode suivante : 

public void aMethodO'nt p) ( 
// ler niveau d'imbrication 
for (int 1=0 j i < 1 ; 1++) { 
// 2e niveau d'imbrication 
if (p<0) { 

// 3e niveau d'imbrication 



possede une profondeur d'imbrication de 3. 
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Tres simple, cette metrique revele rapidement les methodes dont le code est rendu diffi- 
cilement lisible par une trop forte imbrication des structures de controle. Cependant, elle 
ne s'interesse qu'a l'imbrication la plus profonde de la methode et n'offre pas de vision 
d'ensemble, a la difference de la complexite cyclomatique. 



Les mesures de coherence 

Les mesures de coherence analysent les structures internes des elements ou leurs relations 
avec le reste du logiciel. 

La cohesion d'une classe 

La cohesion d'une classe est une mesure censee representer l'equilibre (ou le desequili- 
bre) entre les attributs d'une classe et les methodes de la classe qui y accede. 

Elle est calculee en determinant le nombre moyen de methodes qui accedent a un attribut, 
c'est-a-dire la somme obtenue par l'addition pour chaque attribut du nombre de methodes 
y accedant divisee par le nombre d' attributs, puis en soustrayant a ce resultat le nombre 
total de methodes et en divisant le tout par 1 moins le nombre total de methodes. 

Par exemple, definissons la classe suivante : 

public class Test { 
private int a; 
private int b; 
private int c; 

public Test(int pa, int pb, int pc) { 
a = pa; 
b = pb; 
C = pc; 
} 

public int diviseO { 
return c / (a+b) ; 
} 
} 

D'apres la definition ci-dessus, la cohesion de cette classe est de ([(2 + 2 + 2)/3 - 2]/ 
[1-2]). 

La cohesion doit etre la plus proche possible de 0. Une cohesion proche de 1 indique un 
manque de cohesion et peut suggerer la decomposition de la classe etudiee en plusieurs 
classes ayant une meilleure cohesion. 

Cette metrique doit etre manipulee avec precaution, car elle peut generer de nombreuses 
fausses alertes avec les logiciels ecrits en Java. En effet, le langage Java possede un type 
particulier de classes, appelees JavaBeans, qui a la particularite d'associer deux methodes 
a chaque attribut d'une classe, une methode pour lire la valeur de 1' attribut, le getter, et 
une methode pour la modifier, le setter. Ces classes possedent une cohesion faible alors 
meme qu'elles sont generalement pertinentes dans le contexte du logiciel. 
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A titre d'exemple, la classe de type JavaBean suivante 

public class PersonnePhysique { 
private String genre; 
private String nom; 
private String prenom; 
public String getGenreO { 

return genre; 
} 
public void setGenre(String pgenre) { 

genre = pgenre; 
} 
public int getNomO { 

return nom; 
} 
public void setNomO'nt pnom) { 

nom = pnom; 
} 
public int getPrenomO { 

return prenom; 
} 
public void setPrenomO'nt pprenom) { 

prenom = pprenom; 



a une cohesion de 0,8 ([(2 + 2 + 2)/3 - 6]/[l - 6]) alors que sa semantique est parfaitement 
coherente. Sa decomposition en plusieurs classes n'aurait aucun sens. 

L'indice de specialisation d'une classe 

L'indice de specialisation d'une classe permet d'evaluer la part de reutilisation issue de 
l'heritage au sein de la classe observee. Cet indice est calcule en multipliant le nombre de 
methodes surchargees, c'est-a-dire heritees des ancetres et redefinies dans la classe 
observee, par la profondeur du graphe d' heritage et en divisant le resultat par le nombre 
total de methodes de la classe observee. 

Pour les deux classes Java suivantes : 

public class A { 
private int a; 
publ ic int getA( ) { 

return a; 
} 
public void setAO'nt pa) { 

a = pa; 



public class B extends A { 
private int b; 
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public i nt getB( ) { 

return b; 
} 
public void setBO'nt pb) { 

b = pb; 
) 



) 



l'indice de specialisation vaut 0, car il n'y aucune methode surchargee. 

Par contre, si nous modifions la classe B de la maniere suivante : 

public class B extends A { 
private int b; 
public int getB( ) { 

return b; 
} 
public void setBO'nt pb) { 

b = pb; 
} 

public int getA( ) { 
return b; 



public void setAO'nt pa) { 
b = pa; 

) 



) 



l'indice de specialisation vaut 1 (2 x 2/4), puisqu'il y a deux methodes surchargees, et la 
profondeur du graphe d' heritage est 2. Cette derniere est calculee en prenant en compte 
l'ancetre communde toutes les classes Java, j a va.lang. Object. 

Un indice de specialisation tres fort peut indiquer un probleme de conception au niveau 
de l'utilisation du mecanisme d'heritage puisque la majorite des methodes heritees sont 
surchargees. La encore, il est necessaire de completer la mesure par une revue de code 
pour verifier la validite de son interpretation. Par exemple, si la classe observee (non 
abstraite) herite d'une classe abstraite, autrement dit, si cette derniere a une definition 
incomplete de son comportement et n'est done pas utilisable directement, il est normal 
d' avoir un indice de specialisation fort. 

L'instabilite d'un package 

Comme nous l'avons vu a la section consacree au couplage, la dependance vis-a-vis 
d'entites exterieures est source d'instabilite du fait des effets de bord potentiels issus de 
la modification de ces dernieres. 

La metrique d'instabilite d'un package est calculee en divisant le nombre de classes du 
package observe dependant de classes exterieures (couplage efferent) par la somme de ce 
nombre et du nombre de classes exterieures dependant des classes du package (couplage 
afferent). 
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La figure 3.6 illustre un package compose de deux classes dependantes de trois classes 
exterieures et utilisees par une seule classe exterieure. 
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Figure 3.6 

Calcul de I'indice d 'instability d'un package 

L'indice d'instabilite du package est ici de 0,66 (2/[2 + 1]). 

Un indice d'instabilite fort indique une fragilite du package par rapport a son environne- 
ment exterieur. Cependant, une valeur forte peut etre rencontree sur la couche haute 
(proche de 1'IHM) vis-a-vis des couches basses sans que cela soit anormal. 

Dans le decoupage en couches illustre a la figure 3.7, le package regroupant les traite- 
ments specifiques a 1'IHM (gestion de l'affichage, de la navigation, des erreurs de 
saisies, etc.) ne fournit aucun service aux autres packages mais repose sur le contenu des 
packages contenant les services metier. Son indice d'instabilite est done fort, alors que, 
d'un point de vue conceptuel, il est tout a fait pertinent. 



Figure 3.7 

Decoupage en couches et instabilite 
des packages de haut niveau 
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Les mesures de la qua lite du logiciel 

Les mesures quantitatives de la qualite du logiciel reposent essentiellement sur ce qui est 
directement visible de l'utilisateur ou du testeur, a savoir les anomalies et la performance. 

Les informations sur les anomalies peuvent etre recoupees avec les statistiques issues de la 
gestion de configuration afin d'identifier des zones du logiciel candidates au refactoring. 

Le nombre d'anomalies 

Grace aux outils de gestion d'anomalies, il est possible de dresser un historique des 
anomalies qu'a connues le logiciel selon differents criteres reposant sur les informations 
fournies dans les Aches d'anomalie. Pour que 1' exploitation de cet historique soit effi- 
cace, il est important que les Aches d'anomalies soient remplies avec soin. 

L'idee sous-jacente a cette utilisation de l'historique des anomalies est de trouver les 
zones du logiciel ayant rencontre le plus de bogues. Une zone ayant rencontre beaucoup 
d'anomalies aura souvent tendance a en rencontrer d'autres dans le futur. Cela peut 
s'expliquer par un probleme de conception initial, un developpement bade, etc. 

D'une maniere generale, les maintenances correctives ameliorent rarement la situation, 
du fait des contraintes de delai qui leur sont imposees. 

II est done essentiel d'etre capable d'associer une anomalie donnee a une zone du logi- 
ciel. Plus cette zone est bien circonscrite, plus les operations de refactoring a effectuer 
sont faciles a identifier. Ces zones doivent etre formalisees de maniere a permettre leur 
traitement statistique. 

Concretement, cela consiste en la definition d'une cartographie du logiciel sous forme de 
zones clairement definies. La liste des zones est proposee dans la fiche d'anomalie, a 
charge pour le developpeur de selectionner la ou les zones concernees par 1' anomalie. 

Dans l'exemple de BugZilla illustre a la figure 3.8, le champ « Component » permet de 
delimiter le perimetre d'une anomalie. 



Figure 3.8 

Definition de la zone 
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Dans la definition de la cartographie, il est generalement contre-productif d'avoir un 
decoupage trap fin, car l'affectation de l'anomalie peut devenir rapidement problematique. 
Si la zone permet de savoir quel est le developpeur responsable, la peur du gendarme 
peut de surcroit encourager les developpeurs a brouiller les pistes, ce qui n'est pas du tout 
l'objectif. 

Les changements 

L'outil de gestion de configuration garde la trace des changements effectues sur les 
ressources du logiciel. En complement de l'analyse du nombre d'anomalies, il est inte- 
ressant de recouper 1' identification des zones les plus sujettes a anomalies avec les 
fichiers du referentiel ayant ete le plus modifies. 

Un fichier de code source qui a ete modifie de nombreuses fois par plusieurs developpeurs 
et qui appartient a une zone peu stable est probablement un candidat au refactoring. 

Pour obtenir ce genre d' information, nous pouvons utiliser, par exemple, l'outil StatCVS. 
Ce logiciel se connecte a un referentiel CVS et produit un rapport parametrable, dont une 
partie est reproduite a la figure 3.9. 
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Figure 3.9 

Extraits d'un rapport de StatCVS 
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Les mesures de performance 

Les mesures de performance peuvent etre utiles pour identifier les zones du logiciel dont 
la lenteur n'est pas justifiee. 

Les outils de test de charge que nous avons evoques au chapitre precedent offrent une vue 
macroscopique des performances, car celles-ci sont calculees du point de vue de l'utilisateur 
final. Cette vue macroscopique n'est souvent pas assez fine pour identifier facilement les 
points faibles du logiciel puisque, pour un scenario d'utilisation donne, un grand nombre 
de composants sont generalement impliques de maniere indifferenciee. 

II est done pertinent d'utiliser les services d'un profiler pour s'interfacer etroitement avec 
la machine virtuelle Java et recuperer les statistiques d'execution des objets (nombre 
d'appels, duree de l'execution, etc.) pendant les scenarios d'utilisation. 

La figure 3.10 illustre les resultats obtenus avec Eclipse Profiler (telechargeable sur le 
site Web http://eclipsecolorer.sourceforge.net) pour l'execution d'une application Web avec Tomcat. 
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Figure 3.10 

Statistiques d'Eclipse Profiler sur l'execution d'une application Web avec Tomcat 



Comme nous pouvons le constater avec cet exemple, la totalite des objets est analysee, y 
compris ceux qui constituent le serveur d' applications. Cela noie 1' information perti- 
nente sur les statistiques des objets developpes pour le logiciel. Pour pouvoir y acceder 
directement, les profilers proposent un mecanisme de filtrage qui permet de n'afficher 
que les packages et classes qui nous interessent. 

Le profiler n'est pas suffisant en lui-meme. II n'est qu'un observateur et ne dispose gene- 
ralement pas d'injecteurs permettant de simuler des utilisateurs. Or il est important de 
simuler un comportement proche de la realite afin que le profiler puisse fournir des statis- 
tiques representatives. II est done utile de coupler le profiler avec un injecteur utilise pour 
les tests fonctionnels, a moins de derouler les scenarios d'utilisation manuellement. 
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Le profiler s' integrant directement a la machine virtuelle pour obtenir les statistiques 
d' execution, il degrade de maniere non negligeable les performances. II ne faut done pas 
etre etonne des faibles performances obtenues pendant une campagne de profiling. 

Grace au profiling, la detection des goulets d'etranglement est largement facilitee. Cela 
permet aussi d'identifier les objets tres sollicites par le logiciel, ce qui les rend d'autant 
plus sensibles, meme s'ils ne sont pas intrinsequement tres consommateurs en ressources. 

L'analyse qualitative du logiciel 

L'analyse qualitative consiste a effectuer une serie de revues du logiciel, la plupart du 
temps manuellement. Comme nous l'avons vu a la section precedente, la quantification 
de la qualite du logiciel est loin d'etre aussi evidente et efficace que dans des domaines 
tels que la mecanique et necessite une revue de 1' architecture et du code du logiciel. 

Cette analyse qualitative se fonde sur les informations glanees au cours de l'analyse 
quantitative afin de cibler les revues sur les points sensibles du logiciel, celui-ci ayant 
souvent atteint une telle taille qu'une revue complete est impossible. 

Les revues d 'architecture 

Les revues d' architecture consistent a analyser la structuration des composants du 
logiciel de maniere a detecter d'eventuels points d'inefficience pouvant etre corriges par 
refactoring. 

Pour analyser cette structuration, il est necessaire de se fonder sur la documentation du 
logiciel. Generalement, 1' architecture d'un logiciel peut etre representee efficacement au 
travers de diagrammes UML permettant de s'abstraire du code et de degager ainsi la 
structure du logiciel. La documentation est toutefois souvent desynchronisee par rapport 
aux evolutions du logiciel. 

L'etape prealable a une revue d' architecture consiste a s'assurer que la documentation 
technique necessaire a la comprehension de 1' architecture est en phase avec la realite. 
Cette revue doit rester relativement macroscopique puisque le detail est traite principale- 
ment au niveau des revues de code, que nous abordons plus loin dans ce chapitre. Les 
diagrammes de classes UML, faciles a obtenir par reverse-engineering, permettent 
d'identifier beaucoup d'inefficiences. 

La principale difficulte est de detecter ces inefficiences, car celles-ci dependent fortement du 
contexte du logiciel et du perimetre fonctionnel qu'il couvre. Des problemes generiques ont 
neanmoins ete formalises et fournissent une bonne base pour analyser la qualite d'un logiciel. 

Pour le refactoring, ce ne sont pas les qualites, mais les defauts que nous cherchons a 
identifier. Les antipatterns, e'est-a-dire les fausses solutions a de vrais problemes, dont 
un catalogue est disponible sur http://c2.com/cgi/wiki7AntiPatternsCatalog, peuvent aider a identifier 
ces defauts et a les corriger par refactoring. 

Dans les sections suivantes, nous decrivons quelques antipatterns touchant 1' architecture 
d'un logiciel et nuisant a sa qualite. Nous vous invitons a consulter le catalogue pour 
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decouvrir les autres antipatterns, qui sont autant de lecons par la negative pour la reussite 
de vos projets. 

Les problemes detectes par les revues d' architecture sont souvent tres difficiles a corri- 
ger, car ils touchent a la conception meme du logiciel. Malheureusement pour remedier a 
ce genre de probleme, il faut generalement effectuer une reecriture complete. 

Le marteau en or 

Un des principaux problemes dans la mise en oeuvre de toute nouvelle technologie reside 
dans sa nouveaute. La nouveaute est attrayante. Elle se destine a regler beaucoup de 
problemes, mais elle est mal maitrisee et souvent mal utilisee. C'est un peu comme 
lorsqu'on offre un marteau et quelques clous en plastique a un enfant. Apres qu'il a utilise 
les clous, tous les autres objets deviennent des cibles potentielles, et l'enfant utilisera 
sous peu le marteau mal a propos. 

Dans le monde Java/J2EE, les EJB (Enterprise JavaBeans) ont ete comme un marteau en or. 
Ils se destinaient a devenir le Graal des composants d'entreprise en dissociant les aspects 
techniques (transactions, securite, persistance, etc.) des aspects fonctionnels, reduits a leur 
plus simple expression, c'est-a-dire presque programmables par des non-informaticiens. 
Mal maitrises et mal concus, ils ont malheureusement abouti a des resultats desastreux. 

Dans une revue d'architecture, il est utile d'identifier l'utilisation de marteaux en or, qui 
constituent des sources de complexite inutiles pour les besoins du logiciel, meme s'il faut 
reconnaitre que leur utilisation est souvent si profondement liee au code du logiciel que 
leur eradication peut etre longue et couteuse. 

Les machines de Rube Goldberg 

Rube Goldberg (1883-1970) etait un cartooniste de talent, dont une des specialites etait 
de dessiner des machines d'une complexite extreme (ses « inventions ») pour realiser des 
taches simples ou absurdes. 

La revue d'architecture doit etre l'occasion de prendre du recul par rapport aux services que 
doit rendre le logiciel et d'identifier les machines de Rube Goldberg creees a cette fin. 

De telles « machines » peuvent apparaitre tardivement dans le logiciel du fait d'une 
certaine degenerescence faisant suite a de multiples evolutions non maitrisees (les 
fameuses « rustines »). 

Le cout d'eradication varie fortement d'une machine a une autre. Tout depend de sa 
portee dans le logiciel. Une etude d'impacts precise doit etre menee pour bien estimer les 
consequences d'un tel remplacement. 

Reinventer la roue 

Reinventer la roue est extremement couteux pour les projets informatiques. Cela demande 
non seulement un investissement lors de la premiere version du logiciel mais des couts de 
maintenance dans les suivantes. Comme son nom l'indique, il s'agit d'une occasion 
manquee pour la reutilisation. 
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Cette attitude a souvent pour origine une meconnaissance de la part des developpeurs des 
API a leur disposition, qu'elles soient J2SE/J2EE ou tierces. C'est d'ailleurs une des 
problematiques adressees par les methodes agiles que de favoriser la communication au 
sein des equipes afin de partager les connaissances. 

Lorsque la roue est complexe et mobilise inutilement vos ressources, il peut etre avantageux 
de la remplacer par un produit exterieur. Malheureusement, ce type d' operation peut se 
reveler couteux. Dans le cas des couches basses du logiciel, les remplacer revient genera- 
lement a remplacer les fondations d'un batiment. 

Eviter les dependences cycliques 

La detection de cycles de dependances entre les classes permet d'ameliorer la structura- 
tion du code et de faciliter sa maintenance. Les relations de dependance cycliques, ou 
deux ou plusieurs classes sont dependantes mutuellement (elles s'utilisent les unes les 
autres), rendent generalement le code difficile a comprendre et la maintenance malaisee, 
la modification de l'une pouvant avoir des effets de bord sur les autres. 

Le code source ci-dessous montre un exemple de dependance cyclique entre deux classes 
AetB : 

public class A { 
private B b; 

} 

public class B { 
private A a; 

} 

Toute modification de A modifie B, et inversement, ce qui aboutit a des bogues tres diffi- 
ciles a corriger, le lien de cause a effet pouvant ne pas etre direct, mais provenir des inter- 
actions multiples entre A et B. 

Le plug-in Eclipse Metrics, que nous avons evoque a la section consacree a l'analyse 
quantitative, permet de detecter graphiquement les dependances cycliques au sein d'un 
logiciel, comme l'illustre la figure 3.11. 



© 




°«" 


<l 


1 


*l 



Figure 3.11 

Detection de dependances cycliques avec Metrics 
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Les revues de code 

Les revues de code sont necessaires a tout projet de refactoring. Les techniques prece- 
dentes sont macroscopiques et ne permettent pas de juger « sur pieces » de l'opportunite 
de proceder au refactoring. 

Les revues de code peuvent etre pour partie automatisees, mais elles necessitent toujours 
le jugement humain pour determiner si du code doit etre refondu ou non. 

Les revues de code automatisees 

II existe plusieurs outils, commerciaux ou Open Source, capables d'analyser le code d'un 
logiciel pour identifier de mauvaises pratiques de progr animation. Bien entendu, leurs 
capacites sont limitees, et ils ne permettent de detecter que les problemes les plus simples 
mais tres frequents dans les logiciels. 

Leur fonctionnement est fonde sur un ensemble de regies auxquelles sont confrontees 
toutes les lignes de code source qui composent le logiciel. Ces regies sont fournies en 
standard avec l'outil et derivent des bonnes pratiques de developpement definies par Sun 
ou la communaute Java. Elles peuvent etre parametrees le cas echeant, par exemple, en 
definissant la longueur maximale que peut avoir une ligne de code, voire etre definies 
entierement par l'utilisateur. 

Parmi les problemes typiquement detectes par ce type d'outils, citons les suivants : 

• code mort : variables ou parametres inutilises, importations de packages inutiles ; 

• regies de nommage : respect des bonnes pratiques dans le nommage des differentes 
entites de programmation (classes, methodes, packages, variables) ; 

• regies de formatage du code : lignes de code trop longues, mauvaise utilisation des 
delimiteurs de code, etc. ; 

• regies sur la faille du code : classes ou methodes trop longues, listes de parametres 
excessives, etc. ; 

• regies sur la gestion des exceptions : clauses catch sans contenu, utilisation abusive de 
laclasse Exception, etc. ; 

• regies sur la documentation javadoc : verification de la presence de documentation, 
verification de l'exhaustivite de la documentation, etc. 

La figure 3.12 illustre les resultats obtenus avec l'analyseur de code PMD, ainsi que 
l'ecran d'aide explicitant une regie violee par le logiciel analyse. 

Les problemes detectes par ce type d'outil sont generalement simples a corriger et 
peuvent meme l'etre dans certains cas de maniere automatique (typiquement le forma- 
tage de code). II est done interessant dans le cadre d'un projet de refactoring de prevoir la 
correction de la totalite de ces problemes. 
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Javadoc Declaration Console 
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Figure 3.12 

Analyse de code avec PMD 



PMD Plugin 



Morn de la regie : 



| AvoidReasskjningParametersRu^ 
Classe d 'implementation de b regte : 



| net.sou rceforge. pmd.rules.Avoid Reassigning ParametersRu le 
Message : 



| Avoid reasskjnhg parameters such as "{0}" 
Description : 



Reassigning vakjes to parameters is a questionable 
practice. Use a temporary local variable instead. 



Exemple : 



public class Foo { 
private void foo (String bar) 
bar = "something else"; 



} 

< I 



OK 


Cancel 



II est important de signaler que ces outils generent un nombre colossal d'erreurs lorsqu'ils 
sont executes pour la premiere fois sur du code existant. Cela peut avoir un effet decou- 
rageant pour les developpeurs, d'autant que certaines regies peu critiques peuvent gene- 
rer beaucoup de bruit. II est done essentiel pour reussir la mise en ceuvre de ce genre 
d'outil de configurer intelligemment les regies, de maniere a adresser les problemes critiques 
en premier. 
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Analyse de code avec PMD et Checkstyle 

Dans le cadre de cet ouvrage, nous utilisons PMD pour Panalyse de code. Ce logiciel Open Source est 

disponible sur http://pmd.sourceforge.net/. II offre en standard un grand nombre de regies et permet de 

definir ses propres regies soit en Java, soit avec des requetes specifiers en XPath (XML Path 

Language). PMD dispose d'un outil de detection de duplication de code (copier-coller). 

Checkstyle est un outil Open Source dote de regies souvent complementaires a celles de PMD. C'est la 

raison pour laquelle nous utilisons les deux outils de maniere combinee. Ce logiciel est disponible sur 

http://checkstyle.sourceforge.net. 



Certains de ces outils, comme PMD, permettent de detecter les duplications (copier- 
coller) de code au sein d'un logiciel. Les duplications de code sont souvent nocives pour 
la qualite du code, car si les blocs de code concernes contiennent des bogues ou doivent 
subir des maintenances, il faut modifier plusieurs zones du logiciel, au risque d'en oublier 
ou de mal reporter les modifications. 

La figure 3.13 illustre le resultat d'une recherche de copier-coller avec PMD. 
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Duplcate Code View 



Found a 740 fine (E555 tokens) duplcation in the folowing files : 

Starting at ine 991 of C:\Edpse\workspaceVlGeriea-IHM-1.0\src\org^gereabgieVtfAGenerateurRtf.]ava 
Starting at frie 100S of C:\Edlp5e\work5pace\JGenea-IHM-1.0\src\org\genealogie\pdf\GenerateurPdf.java 



cb.setTextMatrix(gx4[cpf]+ 2 r gy4-48); 
cb.shnwText("M ?"}; 

} 

if( cu.getDecesO!=null ) { 

cb.setTextMatrix(gx4[cpt]+ 2,g y4-56); 
String deces=ai.getDecesO; 
t{ deces.lengtbOas) 

deces=d eces. su bstring(0,26)+ "..."; 
cb.showTcxt( n D " i deecs); 
}ebe{ 

cb.setTextHatnx(gx4[cpt]+ 2 r gy4-56); 
cb.snowTextfD ?"); 
} 
} 

cb.setFontAndS"ize(bf , 10); 
} else f( ec!=nul ) { 

Person neUtJspu=geneabgie.getPersonne(ec.getIdO}; 

String ch=pu.getNamO; 

String chl=pu.getPrenontO; 

String dh2='\ "+ec.getNumeroO-*-" ) n ; 

cb.setTe)rtMarji>:(gx4[q)t] +2,gy4- 1 0) ; 

cb.showTcxt^ch); 

cb.setTextMatrix(gx4[cpt] +2,gy4-20) ; 
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Figure 3.13 

Recherche de duplication de code avec PMD 
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Les revues de code manuelles 



Les revues de code manuelles consistent tout simplement a lire le code. Idealement, ces 
revues de code doivent etre menees par une ou plusieurs personnes d'experience exte- 
rieures au projet. Cela cumule deux avantages : l'experience permet de detecter plus faci- 
lement les problemes, et le fait d'etre exterieur au projet permet d' avoir un ceil neuf sur 
ce qui a ete fait. Comme explique precedemment, la revue de code manuelle doit confirmer 
aussi les problemes potentiels detectes par les mefhodes precedentes. 

Le processus de revue de code manuel peut etre gere au sein d'un outil s'integrant a des envi- 
ronnements de developpement tels qu'Eclipse. L'interet de proceder de la sorte est d'assurer 
une tracabilite entre les problemes detectes lors de la lecture du code et leur resolution. 

En standard, l'environnement Eclipse fournit une liste de taches dont le contenu est defini 
par des commentaires specifiques presents dans le code source du logiciel. 

Considerons le commentaire suivant au sein du code d'une classe Java : 

// TODO supprimer la dependance cyclique 

Le resultat obtenu dans la liste de taches est illustre a la figure 3.14. 
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Figure 3.14 

La liste de taches d 'Eclipse 



Lors de la revue de code manuelle, le relecteur insere ses commentaires signalant les zones 
a refondre et cree en consequence automatiquement des taches dans la liste d' Eclipse. 

Bien entendu, la liste de taches d'Eclipse permet d'ajouter des taches a realiser en dehors 
du code source. 

Le plug-in Eclipse Jupiter (telechargeable sur le site Web http://csdl.ics.hawaii.edu/Tools/Jupiter) 
va beaucoup plus loin dans la formalisation du processus de revue de code. Outre le 
signalement des problemes, il permet de gerer la decision de les prendre en compte ou 
non, ainsi que 1' affectation a un developpeur et la correction des problemes par celui-ci. 



Le processus de refactoring 

Partie I 



Jupiter decoupe le processus de revue de code en trois phases : 

• La phase individuelle, qui consiste a lire le code et a l'annoter pour indiquer les 
problemes detectes. 

• La phase equipe, qui consiste a passer en revue les problemes detectes et a decider s'ils 
doivent etre corriges ou non et de leur affectation le cas echeant a un developpeur. 

• La phase de correction, qui consiste pour chaque developpeur a consulter sa liste de 
problemes a corriger et a effectuer les corrections. 

Lors de la phase individuelle, le ou les experts doivent indiquer les problemes qu'ils 
detectent. Pour cela, il leur suffit de cliquer sur le menu contextuel Add Review Issue sur 
la ligne ou le bloc de code incrimine. Un formulaire doit alors etre rempli pour qualifier 
le probleme detecte (voir figure 3.15). 
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Figure 3.15 

Declaration d'un probleme avec Jupiter 

Une fois la revue terminee, le chef de projet consulte la liste des problemes detectes et 
decide pour chacun d'eux s'il y a lieu de le corriger et quel est le developpeur charge de 
sa correction le cas echeant (voir figure 3.16). 
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Figure 3.16 

Affectation d'un probleme avec Jupiter 
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Apres avoir decide de 1' affectation des problemes aux developpeurs, chacun d'eux a 
acces a sa propre liste de problemes et doit remplir le formulaire une fois celui-ci corrige 
(voir figure 3. 1 7). 



]PR : Supprimer la dependance cydique 
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Figure 3.17 

Changement du statut d'un probleme apres correction 

Une revue de code avec Jupiter n'implique pas obligatoirement 1' ensemble du logiciel. II 
est possible de ne selectionner qu'un sous-ensemble des fichiers source lors de l'initiali- 
sation de la revue. Pour un meme projet Eclipse, Jupiter est en mesure de gerer plusieurs 
revues, chacune ayant un identifiant unique. 

Jupiter a ainsi un perimetre bien plus large que la simple revue de code et peut servir 
d'outil de gestion de projet pour le refactoring. 



Selection des candidats au refactoring 

Grace aux analyses quantitatives et qualitatives, des zones candidates au refactoring ont 
ete identifiees. Dans le cadre d'un projet de refactoring avec des couts et des delais a 
respecter, il est important de bien selectionner les candidats destines a etre traites. 

II n'est pas toujours possible, ni meme souhaitable de corriger tous les problemes detectes. 
Certains d'entre eux generent de telles dependances dans le logiciel que leur refonte 
reviendrait a reecrire le logiciel en totalite, ce qui n'est pas l'objectif d'un projet de refac- 
toring. 

Pour bien decider, il est important de specifier pour chaque probleme ou categorie de 
problemes les risques associes (impacts sur le reste du logiciel, complexite des correc- 
tions a effectuer) et les benefices attendus en terme de maintenance et de qualite de 
service. C'est grace a ces deux informations fondamentales pour la gestion de projet que 
la decision de faire ou de ne pas faire sera prise. 
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Les benefices attendus combines avec les risques associes doivent etre compares au cout 
de ne rien faire. Un projet de refactoring ne devant pas impacter les utilisateurs, les 
contraintes portant sur celui-ci sont tres fortes. II est tentant de ne s'attacher qu'a la 
correction des problemes les plus simples, et done les moins risques. Cependant, il faut 
toujours comparer le risque avec les benefices attendus avant de decider de proceder au 
refactoring ou non. Les problemes non resolus representent aussi des risques et ont un 
cout en terme de maintenance. 



Conclusion 

Maintenant que nous avons vu comment analyser le logiciel et selectionner des zones de 
code a refondre, nous pouvons penetrer au coeur du refactoring. 

Pour cela, il est necessaire de maitriser les quelques techniques de base presentees au 
chapitre suivant. 
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Mise en ceuvre 
du refactoring 



Les techniques abordees dans ce chapitre forment la base du refactoring. II est important 
de bien les comprendre avant d'aborder des techniques plus complexes, presentees dans 
la deuxieme partie de l'ouvrage. 

Nous ne pretendons pas fournir un catalogue exhaustif des techniques existantes, mais 
nous concentrons sur celles qui sont supportees par les environnements de developpe- 
ment logiciel tels que Eclipse, JBuilder ou IntelliJ IDEA. Ce choix est justifie par le fait 
qu'une mise en oeuvre manuelle, sans l'aide d'un outil, d'une technique de refactoring est 
generalement lourde, fastidieuse et sujette a erreur stupide, comme des fautes de frappe. 

Martin Fowler, auteur du livre precurseur Refactoring: Improving the Design of Existing 
Code (Addison Wesley), met a la disposition des internautes sur son site Web un catalogue 
des techniques de refactoring formalisees a ce jour (http://www.refactoring.com/catalog/index.html). 
Celui-ci regroupe aussi bien les techniques abordees dans son ouvrage, que celles 
proposees par des contributeurs exterieurs, a l'image de ce qui existe deja pour les design 
patterns. 

Comme l'a demontre William Opdyke dans sa these Refactoring Object-Oriented 
Frameworks, la plupart de ces techniques sont neutres du point de vue du fonctionnement 
du logiciel, pour peu que des pre- et postconditions soient verifiees. 

Ces verifications sont assurees directement par les assistants fournis par les environnements 
de developpement. Des tests unitaires complementaires doivent souvent etre effectues 
pour s' assurer que le logiciel fonctionne correctement, d'autant plus si des modifications 
manuelles interviennent lors de refontes non automatisees. 
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Support du refactoring de code dans Eclipse 

Les techniques de base du refactoring sont pour beaucoup automatisables. De ce fait, les 
environnements de developpement offrent un support plus ou moins evolue du refactoring. 

Dans le cadre de cet ouvrage, nous avons choisi d'illustrer la mise en oeuvre de ces tech- 
niques avec Eclipse. Cet environnement de developpement Open Source accessible a 
tous offre un support du refactoring equivalent a celui de logiciels comme JBuilder de 
Borland ou IntelliJ IDEA de JetBrains. 

Dans sa version 3.0, Eclipse supporte 1' ensemble des techniques que nous allons aborder 
dans ce chapitre. 

Nous commencons par presenter d'une maniere generale les fonctionnalites de refacto- 
ring d'Eclipse avant d'illustrer leur utilisation concrete. 

Chaque technique dispose d'un assistant, evitant au developpeur de se lancer dans des 
operations fastidieuses. Eclipse propose en outre un mode de previsualisation, qui permet 
de voir avant modification quels sont les elements impactes par le refactoring. Enfin, 
Eclipse considere 1' application d'une technique de refactoring comme une operation 
unique facilitant les retours arriere en cas de probleme. 

Les assistants de refactoring 

L' ensemble des assistants de refactoring est accessible a partir du menu Refactor 
d'Eclipse, comme illustre a la figure 4.1. 
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Eclipse detecte automatiquement si une operation de refactoring est applicable ou non en 
fonction du contexte, c'est-a-dire selon l'element selectionne dans 1'environnement de 
developpement (package dans l'explorateur de package, methode dans l'editeur de code, 
etc.)- Les operations non applicables apparaissent en grise. 

Par ailleurs, un menu Refactor est aussi disponible dans les menus contextuels, accessibles 
par clic droit. La encore, seules les operations applicables dans le contexte sont disponibles. 

Les assistants suivent tous le meme processus : 

• Analyse fine du contexte de l'element a refondre de maniere a s'assurer que les 
preconditions fixees pour l'operation sont toutes respectees. Dans le cas oil celles-ci ne 
seraient pas respectees, un message d'erreur apparait, comme illustre a la figure 4.2. 



Move Method 



J j This method cannot be moved, since no possible new receivers were 
'^r found. An instance method can be moved to source classes that are used 
as types of its parameters or types of fields declared in the same class as 
the method. 



Figure 4.2 

Message d'erreur en reponse a V analyse du contexte d'une operation de deplacement de methode 

• Presentation d'un formulaire a remplir par le developpeur specifiant tous les elements 
necessaires a la realisation du refactoring. La figure 4.3 illustre le formulaire pour le 
changement de signature d'une methode, que nous abordons plus loin. 



Figure 4.3 
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• Previsualisation du resultat du refactoring. Cette fonctionnalite est abordee plus en 
detail a la section suivante. 

Un clic sur le bouton OK lance 1' operation de refactoring. Les erreurs detectees pendant 
cette phase sont signalees et devront etre corrigees ulterieurement. La figure 4.4 illustre 
le resultat d'un changement de type d'un parametre. 



Change Method Signature 



Review the information provided in the list below. CJck 'Continue' to proceed. 
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Type mismatch: cannot convert tram long to mt 
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for (mt [ = d;i<100;i++] { 
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Figure 4.4 

Affichage d'une erreur trouvee pendant le refactoring 

Comme nous pouvons le constater, les assistants de refactoring d'Eclipse ne sont pas 
« magiques », et certaines decisions ne sont pas prises automatiquement, notamment 
celles qui touchent a la semantique du logiciel. Cependant, les taches les plus fastidieuses 
sont effectuees, ce qui procure d'appreciables gains de temps et de securite. 



Le mode previsualisation 

Avant d'effectuer une operation de refactoring, il est utile de mesurer ses impacts. 

Comme explique a la section precedente consacree aux assistants, tout n'est pas automa- 
tisable. Le mode previsualisation permet de visualiser dans un premier temps les proble- 
mes eventuels que genere 1' operation si elle est effectivement realisee (voir figure 4.5). 
En cliquant sur le bouton Continue, la liste des modifications realisees automatiquement 
s'affiche. Ces modifications ne sont qu'une simulation, et le code source n'est pas modifie 
a ce stade. 
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Change Method Signature 
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Figure 4.5 

Previsualisation d'un changement de signature 

En cliquant sur les modifications affichees dans la liste superieure, la partie inferieure de 
la fenetre est mise a jour. Celle-ci presente le code source original (partie gauche) et le 
code source refondu (partie droite) de maniere a visualiser facilement les modifications 
qui sont introduites par 1' operation de refactoring. 

II faut cliquer sur le bouton OK pour voir le refactoring reellement applique au code 
source. Un clic sur Cancel annule le refactoring, et l'assistant se ferme. 



Defaire et refaire une operation de refactoring 

Eclipse considere l'ensemble des modifications liees a une operation de refactoring 
comme une seule et unique operation. II est done possible d'annuler une telle operation 
tres simplement, meme si de nombreux fichiers ont ete modifies. II suffit de choisir 
Refactor dans la barre de menus d'Eclipse et de cliquer sur Undo. 

Cette fonctionnalite n'est toutefois disponible qu'immediatement apres avoir realise 
l'operation de refactoring. Des qu'une autre modification est apportee au code source, 
comme la correction d'un probleme de compilation issu de l'operation de refactoring, 
cette fonctionnalite n'est plus disponible. Son interet est done assez limite. Neanmoins, 
grace a la gestion de configuration, les retours arriere restent simples a effectuer, bien que 
plus fastidieux si de nombreux fichiers sont concernes. 
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Une fois une operation de refactoring annulee, il est possible de la restaurer en cliquant 
sur Redo dans le menu Refactor. A l'instar de la fonctionnalite precedente, celle-ci n'est 
plus disponible des lors que le code source a ete modifie. 

Les techniques de refactoring du code 

Ann de vous permettre de bien comprendre les tenants et aboutissants de chaque technique 
de refactoring, les sections qui suivent decrivent chacune d'elles selon le plan suivant : 

• objectifs de la technique et risques a gerer ; 

• moyens de detection des cas d' application ; 

• modalites d'application et tests associes ; 

• exemple de mise en ceuvre de la technique. 

Les tests unitaires necessaires pour valider le resultat de 1' application de chaque technique 
de refactoring sont presentes de maniere synthetique. Les outils permettant de les realiser 
sont decrits en detail au chapitre suivant. 

Renommage 

Le renommage consiste a modifier le nom de un ou plusieurs elements du code. Pour 
Java, les elements susceptibles d'etre renommes sont les suivants : 

• packages ; 

• classes ou interfaces ; 

• methodes ; 

• attributs de classe ; 

• variables locales ; 

• parametres d'une methode. 

La figure 4.6 illustre le fonctionnement de cette technique. 



Figure 4.6 

Renommage 

a" elements de code 



Code originel 



Code refondu 



public class xYz { 




public class UneClasse { 


private String §]; 






private String unAttribut ; 








public void Uvw() { 

II... 
) 

} 


public void [jneMethode () { 
} 
} 
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Objectifs 



Le renommage est considere comme une technique de refactoring, car 1' absence de 
regies de nommage ou de mauvaises regies peuvent rendre le code source du logiciel 
rapidement illisible. L' absence de regies de nommage est prejudiciable au logiciel en ce 
qu'elle ne favorise pas le travail en equipe et rend difficile 1' integration de nouveaux 
developpeurs. 

Le principe fondamental a respecter est qu'un nom doit etre representatif de la nature de 
l'entite qui le porte. Chaque langage comporte certaines conventions, qui doivent aussi 
etre respectees, au-dela du strict respect des regies imposees par sa grammaire. Par exem- 
ple, en Java le nom d'une classe doit commencer par une majuscule. S'il s'agit d'un nom 
compose, chaque composante est demarquee par sa premiere lettre en majuscule, par 
exemple ContratAssuranceAuto. 

Risques a gerer 

Le renommage est une operation de refactoring fastidieuse, meme avec l'assistance d'un 
outil de type rechercher/remplacer, mais peu risquee du point de vue de l'integrite du 
logiciel. En effet, la majorite des problemes lies au renommage sont detectes lors de la 
compilation. 

Des langages tels que Java permettent le chargement dynamique de classes designees par 
leur nom, via la methode forName de la classe CI ass, utilisee notamment pour charger les 
drivers JDBC. Ce genre de chargement n'est pas detectable lors de la compilation, et un 
renommage peut empecher son bon fonctionnement. 

II faut done veiller a ce que les noms des entites Java soient detectes et modifies dans les 
chaines de caracteres, comme les parametres de la methode forName, par exemple, et dans 
les fichiers de configuration, typiquement le fichier de configuration struts-config.xml 
dans le cas d'une application Web utilisant Struts. La reflexivite, qui permet de decouvrir 
et manipuler un objet de maniere dynamique, peut de meme rencontrer des problemes 
lors d'un renommage. 

Le renommage a par ailleurs un effet de bord nuisible aux futures analyses du logiciel en 
vue d'un refactoring. Le calcul de certaines metriques est sensible aux changements de 
noms, ce qui ne facilite pas l'etude de revolution de ces metriques dans le temps. Par 
exemple, si vous renommez une classe, l'etude des evolutions des metriques qui lui sont 
associees ne peut plus se faire automatiquement. 

Moyens de detection 

Certaines regies de nommage sont formalisables sous forme d'expression reguliere. Par 
exemple, un nom de classe doit respecter 1' expression reguliere suivante 'C[A-Z].*\ 
Elles peuvent aussi etre quantifiables, comme la longueur du nom d'une variable, qui doit 
etre superieure a quatre caracteres. De telles regies sont automatisables a l'aide d'outils 
d' analyse de code tels que PMD ou Checkstyle. 
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Elles ne garantissent pas pour autant la pertinence des noms choisis pour nommer les 
entires du logiciel. Dans la mesure oil elles touchent au domaine semantique, ces regies 
ne peuvent pour l'instant qu'etre verifiees par une revue du code. 

Modalites d'application et tests associes 

Une fois les regies de nommage clairement definies, il est necessaire d'identifier les entites 
qui n'y satisfont pas. II convient d'utiliser pour cela les moyens de detection evoques 
precedemment. 

Le renommage est simple mais fastidieux. II faut non seulement renommer l'entite mais 
aussi modifier en consequence les entites qui y font reference. Les references sont 
presentes dans le code ainsi que dans la documentation (commentaires javadoc) et dans des 
fichiers externes, a l'image des fichiers de configuration XML de certains frameworks 
tels que Struts. Les environnements de developpement comme Eclipse fournissent les 
facilites necessaires pour effectuer ce type d'operation en toute securite. 

Pour renommer un element avec Eclipse, il suffit de le selectionner dans l'explorateur de 
package ou directement dans l'editeur de code, et de choisir Rename dans le menu 
Refactor. Les references a l'element renomme sont automatiquement mises a jour. 

Le renommage avec un outil de gestion de configuration peut etre delicat suivant la facon 
dont ce dernier gere ce type d'operation. Par exemple, avec CVS, un renommage consiste a 
faire une copie portant le nouveau nom puis a supprimer 1' original. La tracabilite est alors 
perdue puisque aucun lien n'est gere entre l'original et la copie, hormis l'eventuel 
commentaire insere lors du commit de la copie dans le referentiel. II est de bonne pratique 
de faire un cliche du logiciel avant de proceder a 1' ensemble des operations de renommage 
afin de faciliter les comparaisons en cas de probleme. II est aussi fortement conseille de 
stopper toute autre modification du referentiel jusqu'a la fin du renommage pour eviter les 
interferences liees aux remplacements des originaux par des copies renommees. 

Une fois le renommage effectue, il est necessaire de le tester. Comme explique prece- 
demment, la majorite des problemes lies au renommage sont detectes lors de la compilation. 
Seuls le chargement dynamique de classes et la reflexion sont susceptibles de rencontrer 
des problemes. II est done necessaire de s' assurer que ces references dynamiques ont 
bien ete modifiees en consequence. 

Exemple de mise en ceuvre 

Supposons un logiciel comportant la classe suivante : 

package appl ication. classes; 
public class cauto { 

public double CalculsL.) { 

} 
} 

Les entites package, classe et methode utilisees dans cet exemple sont mal nominees. 
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Le nom du package ne represente pas la structure du logiciel et ne respecte pas la conven- 
tion en langage Java, qui reserve le premier mot, ici application, soit au code ISO du 
pays (fr, ch, de, etc.), soit a une extension Internet (org, com, net, etc.)- Les deuxieme et 
troisieme mots sont generalement l'editeur et le nom abrege du logiciel. 

Dans ce cas de figure, la verification des premier, deuxieme et troisieme mots peut etre 
faite automatiquement, car elle est exprimable sous forme d'expression reguliere. Par 
contre, la verification de la semantique des noms des packages ne peut se faire que par 
une revue de code manuelle. 

Le nom de la classe n'est pas representatif de sa nature. Par ailleurs, elle ne respecte pas 
la regie Java qui consiste a faire commencer le nom d'une classe par une majuscule. 

Pour la methode, la encore son nom n'est pas representatif de sa fonction (quelle est la 
nature des calculs effectues ?). De plus, elle ne respecte pas la regie qui consiste a faire 
commencer le nom d'une methode par une lettre minuscule. Enfin, le nom d'une 
methode doit etre de preference un verbe. 

Les regies portant sur la casse des lettres sont exprimables sous forme d'expression regu- 
liere et sont done automatisables. Par contre, la verification de la semantique des noms 
doit etre faite par une revue de code manuelle. 

Avant de proceder au refactoring, il est necessaire de definir les regies de nommage. 
Nous donnons ci-apres celles qui sont directement applicables a notre exemple : 

• Les noms de package doivent etre de la forme f r . ey rol 1 es . * et representer la structure 
du logiciel. Ici, nous supposons que nous sommes dans la couche metier du logiciel. 

• Les noms de classe doivent commencer par une majuscule suivie par les mots compo- 
sant le nom de la classe. Chaque mot doit commencer par une majuscule. Le nom de la 
classe doit donner une idee claire de sa nature. 

• Les noms de methode doivent commencer par une minuscule. lis doivent etre des 
verbes, eventuellement completes par un complement d'objet direct donnant une idee 
claire de la nature de la fonction de la methode. 

Le resultat attendu apres application de ces regies est le suivant : 

package f r.eyrol les. application. metier; 
public class ContratAssuranceAuto { 

public double calculePrimeL.) { 



La regie d'or a respecter pour reussir une operation de refactoring est de ne faire qu'une seule 
chose a la fois, en commencant par celle qui a le moins d'impact sur le reste du logiciel. 

Pour le refactoring de cet exemple, nous procederions dans l'ordre suivant : 

1. Renommage de la methode Cal cul s. 

2. Renommage de la classe cauto. 
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3. Renommage du package application. classes. 

Le choix du renommage de la methode en premier au lieu de la classe peut sembler surpre- 
nant puisque les references a une methode d'une classe sont souvent plus nombreuses 
que les references a la classe elle-meme, ce qui a plus d'impact sur le logiciel. Cepen- 
dant, du point de vue de l'outil de configuration, en supposant que nous en utilisions un, 
un renommage de methode n'a aucun impact, contrairement au renommage d'une classe, 
qui a pour consequence de renommer une ressource, en 1' occurrence le fichier qui la 
contient. Les environnements de developpement tels qu'Eclipse automatisent efficace- 
ment ces operations de renommage au niveau du code, si bien qu'il est preferable de 
commencer par la methode. 

Le renommage du package est l'operation la plus delicate, car il impacte non seulement 
toutes les classes qu'il contient, mais aussi toutes celles qui en dependent. 

Avec Eclipse, le renommage de ces trois elements ne pose aucun probleme et se traite 
automatiquement. 

La figure 4.7 illustre 1' assistant de renommage fourni par Eclipse. Outre le renommage 
proprement dit (le nouveau nom est specifie dans le champ New name du formulaire), cet 
assistant permet de mettre a jour toutes les references a l'entite renommee, qu'elles se 
trouvent dans le code, dans les commentaires ou dans les fichiers non-Java. Ici, nous 
desirons modifier les references presentes dans des fichiers XML. Dans ce cas, seules les 
references pleinement qualifiees peuvent etre mises a jour de sorte a eviter les ambiguites. 



Rename Type 



New name: | cauto 

P* Update references 

R" Update textual matches in comments and strings (forces preview) 

R Update fully qualted name h non-Java flies (forces preview) 

Fie name patterns: | *.xml 

The patterns arc separated by commas (* = any string, ? = any character) 



Figure 4.7 

Renommage de la classe cauto avec Eclipse 

Si le projet est couple a un outil de gestion de configuration tel que CVS, l'operation de 
renommage pour les packages et les classes ne supprime pas les originaux. II faut done 
intervenir manuellement dans le referentiel pour les supprimer. 

Une fois l'ensemble des operations effectue, il est necessaire de proceder au test de 
conformite. Comme indique precedemment, celui-ci est reduit a une recompilation si les 
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entites impliquees ne sont pas chargees dynamiquement ou manipulees via la reflexivite. 
Dans le cas contraire, il est necessaire de tester les zones utilisant ces techniques. Cela 
peut generalement se faire sous forme de tests unitaires. 

Extraction d'une methode 

L' extraction d'une methode consiste a selectionner un bloc de code consistant, dont 
l'execution peut se faire de maniere independante aux variables pres, et a le transformer 
en une methode. 

L' extraction d'une methode est utile principalement dans les deux cas suivants : 

• La methode contenant le bloc de code a extraire est complexe ou longue. En effectuant 
l'extraction, nous isolons une partie du traitement et rendons ainsi la methode source 
moins complexe et plus lisible. Generalement, les methodes extraites sont privees, car 
leurs details d' implementation ne sont, par principe, pas visibles de l'exterieur. 

• Le bloc de code constitue un element reutilisable au sein de la methode source ou au 
niveau de la classe, voire au-dela. II est done interessant de le transformer en une methode 
reutilisable. Si la reutilisation est strictement interne a une methode ou a une classe, la 
methode doit etre privee, sinon elle peut etre soit protegee, soit publique, en fonction du 
mode de reutilisation (reutilisation par les descendants ou par des classes externes). 

Dans les deux cas, il est important de veiller a ce que la methode extraite soit pertinente, 
e'est-a-dire que son contenu ait une signification en lui-meme afin de sauvegarder la lisi- 
bilite du code, et qu'elle n'ait aucune adherence vis-a-vis de la methode source afin de 
faciliter sa reutilisation eventuelle. 

La figure 4.8 illustre un exemple d' extraction de methode. 



Figure 4.8 

Extraction 
d'une methode 



Code originel 



public class UneClasse { 



public void uneMethode () { 
blocDefcode 1 ; 
[blocDeCode 2; 
blocDeCode 3; 



Code refondu 



public class UneClasse { 



private void methode 2() { 

blocDeCode 2; 
} 



public void uneMethode () { 
blocDeCode 1; 
methode2(); 
blocDeCode 3; 

} 



L'extraction de methode comporte peu de risques, hormis une regression du fonctionnement 
du bloc de code extrait et de la methode source. 
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Meme s'il est tentant de realiser une extraction de methode strictement technique afin de 
reduire la complexite de la methode source, il est important de conserver la semantique 
du bloc extrait. 

En cas d' extraction de methode en vue de sa reutilisation, il faut veiller a ce que toutes les 
occurrences du bloc de code soient bien remplacees par la nouvelle methode afin de 
maximiser les gains de la reutilisation. Plus il y a d'occurrences a remplacer, plus le 
risque de regression est important. 

Moyens de detection 

Selon le cas de figure, reduction de la complexite ou reutilisation, les moyens de detec- 
tion different. 

Dans le cas de la reduction de la complexite, nous pouvons nous reposer sur les metri- 
ques afin de detecter les methodes pouvant abriter des blocs de code candidats a une 
extraction. Les metriques les plus pertinentes dans ce cas de figure sont les suivantes : 

• Nombre de lignes de code. Une methode ayant un nombre important de lignes de code 
(superieur a 30) gagne generalement en lisibilite en etant divisee en plusieurs morceaux. 

• Profondeur d' imbrication des blocs de code. Une methode ayant une forte imbrica- 
tion peut etre simplifiee en extrayant un ou plusieurs niveaux d' imbrication au sein de 
methodes externes. 

• Complexite cyclomatique. Une methode ayant une complexite cyclomatique impor- 
tante (superieure a 20) peut etre simplifiee en externalisant dans de nouvelles methodes 
certaines branches de son graphe (voir au chapitre 3 la section consacree au calcul de 
la complexite cyclomatique ). 

Ces metriques sont des indicateurs susceptibles de generer de fausses alertes. II est 
fondamental d'effectuer une revue de code manuelle afin de selectionner les blocs de 
code qui seront effective ment extraits. 

Dans le cas de la reutilisation, il est possible d'utiliser un analyseur de code comme PMD 
pour detecter la duplication de code par copier-coller. Ces duplications nuisibles a la 
maintenance peuvent generalement etre remplacees par une methode. Malheureusement, 
les analyseurs de code effectuent souvent des comparaisons litterales et sont done depen- 
dants des noms de variables, de la structuration du code, etc. Par exemple, les duplica- 
tions implementant un meme algorithme avec de legeres modifications dans les noms de 
variables ne seront pas detectees. Ces cas plus complexes ne peuvent done etre detectes 
que par une revue de code manuelle. 

Modalites d'application et tests associes 

L'extraction d'une methode est un processus assez simple. En premier lieu, il s'agit 
d' identifier les cas de figure suivants : 

• Les parametres de la methode source necessaires a 1' execution de la methode extraite 
deviennent aussi des parametres de cette derniere. 
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• Les variables locales partagees par le bloc extrait et le reste de la methode source 
deviennent des parametres de la methode extraite. 

• Les variables locales utilisees exclusivement par la methode extraite sont extraites en 
meme temps que le bloc. 

Le principal probleme de l'extraction de methode reside dans les parametres en sortie. 
Une variable locale de la methode source passee en parametre a la methode extraite n'est 
generalement pas modifiable par cette derniere (passage de parametre par valeur). Seuls 
les parametres ayant un type mutable, c'est-a-dire une classe disposant de methodes 
permettant de modifier la valeur de ses attributs, sont modifiables par la methode extraite. 
Si les variables locales ne sont pas mutables, par exemple, les types de base, comme les 
entiers ou les chaines de caracteres, il est necessaire de les encapsuler dans des classes 
mutables. 

La derniere operation consiste a deplacer le bloc de code de la methode source pour le 
placer dans la methode extraite et remplacer le vide ainsi forme dans la methode source 
par un appel a la methode extraite. 

Dans le cas d'une extraction en vue de la reutilisation, il faut completer cette operation 
par une recherche des dupliquas afin de les remplacer par des appels a la methode extraite. 
L'extraction de methode en vue de la reutilisation est delicate lorsque la duplication 
implique plusieurs classes sans rapport les unes avec les autres. II est alors necessaire de 
reflechir a l'opportunite d'une classe utilitaire accessible par toutes ces classes afin d'heberger 
la methode extraite. 

Avec Eclipse, l'extraction de methode est entierement automatisee. Les variables locales 
externes au bloc a extraire sont transformees systematiquement en parametres. Si tel ne 
doit pas etre le cas, il faut inclure dans le bloc extrait la declaration de ces variables. 

La recherche de dupliquas est limitee a la classe contenant le bloc de code extrait. II s'agit 
cependant d'une recherche « intelligente » puisqu'elle sait s'abstraire des changements de 
variables. Par exemple, les deux expressions suivantes sont considerees comme des dupliquas : 

III expression extraite : annees(date)*365+mois(date)*30+jours(date) 
nbJoursDeb = annees(debut)*365+mois(debut)*30+jours(debut) ; 
nbJoursFin = annees(fin)*365+mois(fin)*30+jours(fin) ; 

Du point de vue de la gestion de configuration, une extraction de methode ne pose pas de 
probleme particulier, sauf en cas d'extraction en vue d'une reutilisation impliquant un 
grand nombre de classes differentes. De nombreuses ressources doivent en ce cas etre 
modifiees, avec autant de conflits potentiels a gerer, et une classe utilitaire, et done une 
nouvelle ressource, doit etre creee. 

Pour tester le resultat, il est necessaire de mettre en place des tests unitaires de la 
methode source afin de verifier que son fonctionnement n'est pas altere par l'extraction. 
Dans le cas d'une reutilisation ayant entraine la suppression de dupliquas, il est neces- 
saire de tester de la meme maniere 1' ensemble des methodes impactees. Enfin, il est 
souhaitable de definir des tests unitaires specifiques pour la methode extraite si celle-ci 
est destinee a etre reutilisee ulterieurement. 
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Exemple de mise en oeuvre 

Supposons que nous disposions d'une classe PersonnePhysique dont un des attributs est un 
tableau listant les enfants de la personne et deux methodes permettant de savoir s'il s'agit 
de garcons ou de filles : 

public class PersonnePhysique { 
//... 
PersonnePhysique[] enfants; 

public boolean possedeGarcon( ) { 
boolean trouve = false; 
int i = ; 

while ( (i<enfants.length)&& Itrouve) { 
if (enfants[i] .getGenret )=='M' ) { 

trouve = true; 
} 

i++; 
} 

return trouve; 
) 

public boolean possedeFil le( ) { 
boolean trouve = false; 
int i = 0; 

while ( (i<enfants.length)&& Itrouve) { 
if (enfants[i] .getGenret )==' F' ) { 

trouve = true; 
} 

i++; 
} 

return trouve; 
} 

Grace au detecteur de dupliquas fourni par PMD, nous obtenons le resultat illustre a la 
figure 4.9. 
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Duplicate Code View 



Found a B Inc (36 tokens) dupScation in the following Acs : 

Starting at Ine 12 of C:\Ectpse\workspace\Refactonng\src\fAeyrotes\exemples\Personne.java 
Stalling at ine 24 of C:\Edip5e\work5pace\Refactoring\5rc\fr\eyiTole5\exennple5\Personne.iava 



pubic boolean possedeFleO { 
boolean trouve = false; 
inti= 0; 

write ((i<enfants.length)8& Itrouve) { 
r (enfants[(].getGenreO=='F0 {□ 



Figure 4.9 

Resultats de la recherche de dupliquas avec PMD 
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Afin d'ameliorer la reutilisation au sein de la classe PersonnePhysique, il est interessant 
d'extraire le bloc de code correspondant a la recherche et de le rendre independant du 
genre recherche. 

Pour cela, nous modifions le code des deux methodes afin de rendre le bloc de code 
correspondant a la recherche independant du genre recherche (les zones en gras indiquent 
les modifications) : 

public boolean possedeGarcon( ) { 
char genreRecherche = 'M'; 
boolean trouve = false; 
Int 1-0; 
while ( (i<enfants.length)&& Itrouve) { 

if (enfants[i ] .getSexe( )==genreRecherche) { 

trouve = true; 
} 

i++; 
} 

return trouve; 
} 

public boolean possedeFil le( ) { 
char genreRecherche = 'F'; 
boolean trouve = false; 
int i = 0; 
while ( (i<enfants.length)&& Itrouve) { 

if (enfants[i ] .getSexe( )==genreRecherche) { 

trouve = true; 
} 

i++; 
} 
return trouve; 



Nous pouvons ensuite utiliser 1' assistant d'extraction de methode d'Eclipse. Pour cela, 
nous selectionnons le bloc de code de la methode possedeGarcon depuis boolean jusqu'a 
l'instruction return incluse, puis nous lancons l'assistant via le menu Refactor en selec- 
tionnant Extract Method (voir figure 4.10). 

Nous appelons ici la methode extraite rechercheGenre comme etant privee puisqu'elle 
n'est pas censee etre utilisee ailleurs qu'au sein de 1' implementation de la classe. Cette 
methode possede un parametre genreRecherche qui specifie le genre a rechercher. 

Nous constatons que l'assistant a trouve un dupliqua (la troisieme case a cocher sur la 
figure). Avant de proceder au refactoring, nous pouvons previsualiser le resultat, comme 
illustre a la figure 4.11. 

L' extraction est correcte et prend bien en compte les deux methodes possedeGarcon et 
possedeFi 1 1 e. Nous pouvons done cliquer sur le bouton OK pour proceder au refactoring. 
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Figure 4.10 
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rechercheGenre 
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Original Source 



Refactored Source 



public boolean pnsserleGarr.nn () [ 
char genr eRe cherche = 'M'; 



public boolean possedeGarconO { 
char genreRecherrhe = 'M 1 ; 



boolean trouve 



false; 



int i = Ox- 
while ( (i<enfa.nts . length) && 3 trouve) { 

if (enfants : [ij| .getGenre() — genreReeherc 
Lruuvti = true; 

> 

} 

return trouve; 



return rechercheGenre { genr eRecherche J ; 



private boolean rechercheGenre (char genreRec 
boolean trouve - false; 



public boolean pcssedeFille () { 



int 1=0; 

while ( (i<enf ants . length) && 1 trouve) { 

if tRntants Li ] .get-Genre U==gexireRec:her 
trouve = true; 

\ 

i++; 
} 
return trouve; 



* 



■i 



> 



Figure 4.11 

Previsualisation de V extraction de methode 
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Pour un exemple aussi elementaire, il est peu utile de mettre en place un test unitaire. Par 
contre, pour une extraction plus complexe, ceux-ci sont necessaires. Dans ce dernier cas, 
il est conseille de developper les tests unitaires pour la methode source avant le refactoring 
arm de tester leur validite et celle du code sous-jacent. Une fois le refactoring effectue, il 
suffit de rejouer les tests unitaires sans modification puisque l'extraction de methode doit 
etre transparente du point de vue des utilisateurs de la methode source. Une anomalie 
indique immediate ment que l'extraction a eu des effets de bord a corriger. 



Extraction de variable locale 

L'extraction de variable locale consiste a remplacer une expression au sein d'une 
methode par une variable locale dont la valeur d'initialisation est celle retournee par 
l'expression (voir figure 4.12). 



Code originel 



Code refondu 



public class UneClasse { 

public void uneMethode () { 
if (expressionComplexe )-)f - 

II... 
} 

} 

} 




public class UneClasse { 
public void uneMethode () { 


boolean v = expressionComplexe ; 


if (v) { 
II... 
} 
} 

} 



Figure 4.12 

Extraction de variable locale 

Des expressions longues ou complexes apparaissent souvent dans le code. Ces expressions 
sont difficiles a lire et a deboguer. En cas d'expression complexe, la partie de l'expression 
incriminee est souvent dure a isoler dans le flot d'execution. 

Par ailleurs, une meme expression peut etre utilisee a divers endroits au sein d'une methode. 
Sa faible faille, d'une ligne de code au grand maximum, ne justifiant pas la creation d'une 
methode, il est interessant d'utiliser une variable locale pour n'effectuer revaluation de 
l'expression qu'une seule fois. Ainsi, nous gagnons en performance, puisque l'expression 
n'est evaluee qu'une seule fois, et en maintenance, puisque, en cas de bogue dans 
l'expression, seule l'initialisation de la variable doit etre modifiee. 

Par exemple, pour la condition d'une boucle, il peut etre interessant d'en remplacer une 
partie par une variable locale de maniere a simplifier la lecture de la condition. 

Les risques associes a ce type d'operation tres localisee, ou seule une methode est 
concernee, sont extremement faibles. Une verification soigneuse de la non-regression du 
fonctionnement de la methode suffit a s'assurer que l'operation s'est bien passee. Dans le 
cas contraire, un retour en arriere est tres peu couteux et facilement gerable avec un outil 
de gestion de configuration. 
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Moyens de detection 

La complexite cyclomatique nous aide a detecter les expressions complexes pouvant 
beneficier d'une extraction de variable locale. Malheureusement, cet indicateur est beau- 
coup trap general pour couvrir specifiquement ce probleme. En effet, la complexite d'une 
methode peut avoir de multiples origines et pas uniquement la complexite de certaines 
expressions. 

La complexite cyclomatique ne s'interesse qu'aux conditions. Si une expression complexe 
n'est pas une condition, par exemple, A| | (B&& !C) 1 1 D&&E, mais un calcul complexe, elle 
n'a pas plus d'impact qu'une autre expression plus simple. Seule une revue de code permet 
de detecter efficacement ce type d' expression complexe. 

Nous pouvons eventuellement nous reposer sur la capacite d'un analyseur de code tel que 
Checkstyle pour detecter les lignes tres longues, mais beaucoup de fausses alertes sont 
generees par les chaines de caracteres dans le code, comme dans l'exemple suivant : 

I System. out. println( "Ceci une chaine de caracteres tres longue pouvant generee une 
fausse alerte prejudiciable a la detection d'expressions complexes a refondre"); 

Modalites d'application et tests associes 

L extraction de variable locale est une operation simple a realiser. II s'agit de definir une 
variable locale dont le type est celui de la valeur renvoyee par revaluation de l'expression a 
extraire. Ensuite, il faut copier l'expression a extraire et la coller dans la partie droite de 
l'expression destinee a initialiser la variable locale. Enfin, il faut remplacer l'expression 
extraite par la variable locale partout ou la premiere etait utilisee. 

Avec Eclipse, l'extraction d'une variable locale est entierement automatisee. L' assistant 
est accessible via le menu Refactor en selectionnant Extract Local Variable. 

Du point de vue de la gestion de configuration, ce type d'operation ne pose strictement 
aucun probleme, car il s'agit d'une operation purement locale a une classe. Le retour en 
arriere s'effectue sans difficulte. 

Des tests unitaires doivent etre realises afin de verifier que l'extraction de variable n'a pas 
fait regresser la methode modifiee. 

L'expression servant a l'initialisation de la variable locale peut ensuite etre extraite sous 
la forme d'une methode suivant la technique que nous avons vue precedemment. 

Exemple de mise en ceuvre 

Supposons que nous ayons une classe Cylindre dont une methode permet de calculer le 
volume d'un cylindre : 

public class Cylindre { 
private double rayon; 
private double hauteur; 

public Cyl indre(final double pRayon, final double pHauteur) ( 
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rayon = pRayon; 
hauteur = pHauteur; 



publ ic double vol ume( ) { 
return 3.14 * rayon * rayon 



hauteur; 



Le calcul du volume d'un cylindre equivaut a multiplier l'aire du disque de base du cylindre 
(en gras dans le code) par la hauteur de ce dernier. Nous pouvons extraire le calcul de 
l'aire de la base afin de rendre la formule plus lisible. 

Pour cela, il suffit de selectionner la sous-expression correspondante (en gras dans le 
code) puis d'ouvrir le menu contextuel par clic droit et de choisir Ref actor/Extract Local 
Variable. 



Extract Local Variable 



Variable name:'] aireBase 

W Replace al occurrences of the selected expression with references to the local vanable 

I - Declare the local variable as finar 

Signature Preview: double aireBase 



Figure 4.13 

Extraction de la variable locale aireBase 



Nous appelons ici la variable locale, recevant la valeur de retour de l'expression extraite, 
ai reBase, et cochons l'option permettant de remplacer toutes les occurrences de l'expression 
extraite, ici une seule. 

L'option permettant de definir la variable locale comme final offre une securite en cas de 
reutilisation (la variable locale est definie comme etant une constante). Ici, ce n'est pas 
justirie puisqu'il n'y a qu'une occurrence a remplacer. 

Avant de realiser l'extraction, nous pouvons previsualiser les modifications a venir, 
comme illustre a la figure 4. 14. 

Constatant que l'extraction est correcte, nous pouvons cliquer sur le bouton OK pour 
proceder au refactoring. 
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Original Source 



Refactored Source 



s f r . cyrollcG . cxcmplcs; 

class Cylindre { 
Lvata double rayon; 
Lvate double hauteur ; 

3lic Cyl indre (final double pRayon, final 
rayon = pRayon; 
hauteur =paauteur; 



?llc double volume () 



fr.cyrollcs . cxcraplcs; 

lass Cylindre { 
rata doubla rayon; 
rate double hauteur; 

Lie Cyl incire (final double pRayr>n,fin 
rayon = pRayon; 
hauteur =ptiauteur; 



Lic double volume ( ) 



return 3.14 * rayon * rayon * hauteur 



double aireBase =3.14 * rayon 

return aireBase * hauteur; 



<_ 



- 






v 



> 

Cflnoel 



Figure 4.14 

Liste des modifications liees a V extraction de la variable locale 



Le calcul d'aire de la base pouvant etre interessant dans d'autres cas, nous pouvons effec- 
tuer une extraction de l'expression d'initialisation de la variable locale en utilisant la 
technique d'extraction de methode abordee precedemment. Nous aboutissons au code 
source suivant : 

public class Cylindre { 
private double rayon; 
private double hauteur; 

public Cyl indre(final double pRayon, final double pHauteur) { 

rayon = pRayon; 

hauteur = pHauteur; 
} 
public double aireBaseO { 

return 3.14 * rayon * rayon; 
) 
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publ ic double vol ume( ) { 
double aireBase = aireBaseO; 
return aireBase * hauteur; 



Une operation complementaire, que nous verrons en fin de chapitre, permet de remplacer 
la variable ai reBase dans le calcul du volume par un appel direct a la methode ai reBase. 

Du point de vue des tests, il est preferable de creer des tests unitaires pour la methode 
vol ume, s'ils n'existent pas deja, avant l'application du refactoring afin de valider le code 
originel de la methode vol ume. Une fois le refactoring effectue, nous les utilisons pour 
verifier qu'il n'y a pas eu regression. 

Extraction de constante 

Au sein de methodes, il est frequent de rencontrer des valeurs litterales, comme des 
nombres ou des chaines de caracteres, directement utilisees dans les expressions. 

L' extraction de constante consiste a stacker ces valeurs litterales dans des variables non 
modifiables, ou constantes, et a les remplacer dans le code par ces dernieres (voir 
figure 4.15). 



Code originel 




Code refondu 


public class UneClasse { 




public class UneClasse { 


^private final static int CONSTANTE = 128 ; 


r 

public void JneMethode () { 
intv2 = ^28j*v1; 




public void uneMethode () { 


inU/2 = CONSTANTE * v1; 


} 




} 
} 



Figure 4.15 

Extraction de constante 



Dans certains cas, 1' utilisation de valeurs litterales nuit a la comprehension du code. Par 
ailleurs, ces valeurs litterales pouvant etre utilisees en plusieurs endroits dans le logiciel, 
il est tres utile de les centraliser de maniere a faciliter leur gestion. 

Les risques lies a l'extraction d'une constante sont presque nuls. Comme une valeur litte- 
rale n'est pas calculee, il ne peut y avoir de regression lors de son remplacement par une 
constante, sauf erreur de manipulation lors du refactoring, bien entendu. 



Le processus de refactoring 

Partie I 

Moyens de detection 

Les analyseurs de code tels que Checkstyle peuvent detecter tres facilement l'utilisation 
de valeurs litterales directement dans le code sans passer par des constantes. 

II est neanmoins necessaire de verifier chaque alerte generee par l'analyseur de code afin 
de valider la pertinence du remplacement de la valeur litterale incriminee par une cons- 
tante. Par exemple, dans certains calculs, le remplacement d'une valeur litterale par une 
constante n'a aucun interet et peut meme avoir un effet contre-productif, tel qu'une 
moins bonne comprehension du code, si nous changeons toutes les valeurs litterales 
d'une formule mathematique bien connue. 

Modalites d'application et tests associes 

Si la constante est strictement locale a une classe, il suffit de creer un attribut prive non 
modifiable (voir V exemple de mise en ceuvre) et de l'initialiser avec la valeur litterale. S'il 
s'agit d'une constante utilisee par plusieurs classes, deux options se presentent : 

• II existe un lien semantique fort entre la constante et une de ses classes utilisatrices, par 
exemple, les couleurs primaires exprimees en composantes rouge, vert et bleu et la 
classe Coul eur. Dans ce cas, les constantes doivent etre des attributs publics non modi- 
fiables de la classe. 

• II n'existe pas de lien semantique fort. Dans ce cas, nous stockons la constante dans 
une interface specifique. Si plusieurs constantes ont un lien semantique entre elles, 
elles doivent etre stockees au sein de la meme interface. 

Bien entendu, il convient de veiller a remplacer chaque valeur litterale extraite par la 
constante correspondante afin de maximiser les gains de l'operation. 

Dans le cas particulier des chaines de caracteres, il peut etre interessant de les externaliser 
dans des fichiers de configuration. Si le logiciel est destine a etre traduit dans differentes 
langues, cela peut se faire tres facilement et sans compilation specifique du logiciel pour 
chaque nouvelle langue. 

Avec Eclipse, l'extraction de constante est entierement automatisee mais ne permet pas 
de transferer les constantes dans une interface dediee. L' assistant est accessible via le 
menu Refactor en selectionnant Extract Constant. 

Eclipse permet aussi d'effectuer tres simplement l'externalisation des chaines de caracteres 
dans un fichier de proprietes. Pour cela, il suffit d'utiliser 1' assistant accessible via le 
menu Source en selectionnant Externalize Strings. Cet assistant cree un fichier de 
proprietes contenant toutes les chaines de caracteres, chacune etant identifiee au sein du 
fichier par une cle. 

Au sein de la classe, les chaines de caracteres sont remplacees par un appel a la methode 
getString de la classe Messages, qui est creee automatiquement par l'assistant, en lui 
passant en parametre la cle de la chaine. Pour modifier une chaine de caracteres, il suffit 
de modifier le fichier de proprietes directement sans recompilation. 
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II est possible de creer plusieurs fichiers de proprietes, un par langue, pour internatio- 
naliser le logiciel. Le nom du fichier de configuration contient le code ISO de la langue 
(FR pour le francais, par exemple). La classe Messages selectionne automatiquement le 
fichier de proprietes correspondant a la langue de l'utilisateur grace aux fonctions 
d'internationalisation de Java. 

Du point de vue de la gestion de configuration, l'impact de l'extraction depend de l'eten- 
due de 1' utilisation de la constante. Meme si un grand nombre de ressources sont impac- 
tees, il s'agit de modifications mineures, facilement gerables. 

Pour les tests, normalement une simple recompilation est suffisante. Si le remplacement 
n'est pas bien fait, les effets de bord sont tout de suite detectes par le compilateur, 
l'expression dans laquelle se trouvait la constante n'etant plus correcte syntaxiquement. 

Exemple de mise en oeuvre 

Supposons la classe suivante representant un disque : 

package f r.eyrolles.exemples; 
public class Disque { 

private double rayon; 

public Disque(final double pRayon) { 
rayon = pRayon; 

} 

public double perimetreO { 
return 3.14 * rayon * 2; 
} 



public doubl e ai re( ) { 
return 3.14 * rayon 



rayon; 



Les methodes perimetre et ai re utilisent les memes constantes, a savoir 2 et 3,14 c'est-a-dire 
une valeur approximative de Pi. 

En utilisant Checkstyle, le nombre 3,14 est immediatement detects (tous les nombres 
differents de 0, 1 ou 2, appeles nombres magiques, sont detectes), comme l'illustre la 
figure 4.16. 



) errors, 2 warnings, infos (filter matched 2 of 2 720 items) 



Console 



Description 



Resource 



M 



Maat Number: 3. 



s Magic Number: '3.14' is a magic number. 

Figure 4.16 

Detection des nombres magiques avec Checkstyle 



Disque.java 
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Dans cet exemple, il est interessant de transformer 3,14 en une constante representative 
de Pi de facon a rendre les calculs plus lisibles et a ameliorer a moindre cout 1' approxi- 
mation de Pi puisque sa valeur est centralisee au niveau d'une constante unique. Par 
contre, il n'y a aucun interet a transformer la valeur 2 puisqu'elle n'a pas de signification 
en dehors de la formule. 

Pour extraire 3,14, il suffit de selectionner cette valeur a extraire dans l'editeur de code et 
d'utiliser le menu Refactor en selectionnant Extract Constant. Pour remplacer toutes les 
occurrences de 3,14 dans le code, il est necessaire de cocher la premiere case (voir 
figure 4.17). 



Extract Constant 



Constant name: | PI 

Access modffier: C~ public f~ protected C default £• private 

W Replace aB occurrences of the selected expression with references to the constant 

l~ Quaify constant references with dass name 



Signature Preview: private static final double PI 



Figure 4.17 

Extraction de la constante PI 



Nous definissons le nom de la constante, en l'occurrence PI, uniquement en majuscules 
pour respecter la convention de nommage de Java concernant les constantes et selection- 
nons 1' option permettant de remplacer toutes les occurrences de la valeur litterale par la 
constante correspondante. 

La constante ayant une portee privee, elle ne peut etre utilisee qu'au sein de la classe dans 
laquelle elle est definie. Si nous souhaitons la reutiliser ailleurs dans le code, il nous faut 
regler sa portee de maniere qu'elle soit publique. Nous recommandons en ce cas de 
cocher la seconde option afin que les references a la constante indiquent clairement son 
origine, c'est-a-dire la classe ou elle est definie. 

La figure 4.18 illustre la liste des modifications liees a l'extraction de la constante. 

Nous constatons que l'extraction est correcte et qu'elle prend bien en compte les deux 
methodes perimetre et aire. Nous pouvons cliquer sur le bouton OK pour proceder au 
refactoring. 
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Changes to be performed 



£ ft 



:- [^Jtf 1 Dequejava - Refactoring/src/ft/eyrotes/exemples 
i-, 0© Disque 

j 0fe Declare constant 
B e penmetreO 

f^l^ Reptece expression with a constant i^eference 
a-0 e aireO 

Pl^i Reptace expression with a constant reference 



J] Dtsque.java 



O i> 



Original Source 



pub! 



Retactored Source 



blic class Tii ^qne { 



lie class Disque 



private double rayon; 



public Disque {final double pRayon) 
rayon — pRayon; 



public double perimetre ( ) 



return 3.14 * rayon * 2; 



public double aire ( ) { 



return 3.14 * rayon * rayon; 



private static final double PI = 3.14 
private double rayon ; 



public Disque (final double pRayon) { 

rayon — pRayon; 
} 

public double perimetre ( ) { 



return PI * rayon * 2; 



public double aire ( ) 



return Fl * rayon * rayon; 



- 



<l 



i 



Figure 4.18 

Liste des modifications liees a 1' extraction de la constante 

Du point de vue des tests, la realisation de l'operation de refactoring avec l'assistant ne 
doit normalement pas generer de regression, cette refonte etant totalement neutre du 
point de vue des traitements. 



Remarque 

La constante PI est deja presente dans I'API standard de J2SE (j ava . 1 ang . Math . PI). En toute rigueur, 
e'est cette constante qu'il faudrait utiliser. 
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Extraction d'interface 

L' extraction d' interface consiste a creer une interface a partir d'une classe existante (voir 
figure 4.19). II est possible de remplacer toutes les references a cette classe par 1' interface 
nouvellement creee lorsque cela est possible, c'est-a-dire quand les references ne dependent 
pas de methodes ou d'attributs absents de 1' interface. 



Code originel 




Code refondu 


public class UneClasse { 




public interface Unelnterface { 

public void uneMethode (); 
} 


r 




public void uneMethode () \ 

> 

} 




'puBHc "class DneClasselmplements Unelnterface { 

public void uneMethode () { 

II... 
} 

} 



Figure 4.19 

Extraction d'interface 



Le principal objectif d'une extraction d'interface est de decorreler les services fournis par 
une classe de leur implementation. En effet, il peut etre utile d' avoir la capacite de modifier 
la classe d' implementation sans impacter 1' ensemble du logiciel du fait des references 
statiques a la classe en question. Nous pouvons, par exemple, reporter le choix de 
1' implementation a utiliser au moment ou le logiciel est lance en utilisant un fichier de 
configuration donnant la classe a charger. 

L' extraction d'interface peut aussi se reveler utile lorsqu'un ensemble de classes partagent 
un certain nombre de methodes communes sans pour autant justifier la mise en place 
d'un arbre d'heritage pour les lier. Grace a cette interface, des operations complexes 
peuvent etre definies independamment des details d'implementation. 

C'est typiquement le cas pour les classes modelisant des structures de donnees, qui four- 
nissent toutes des fonctions similaires, telle une methode de recherche d'un element. Du 
fait de leur grande variete, elles ne justifient pas la mise en place d'un arbre d'heritage 
global les regroupant toutes. Rappelons que l'heritage est un mecanisme de reutilisation 
fort et structurant, qui ne doit etre utilise que dans les cas oil la filiation est clairement 
marquee et oil les descendants beneficient des proprietes dont ils ont herite. Dans le cas 
d'une minibase de donnees, l'utilisation d'interfaces permet au reste du logiciel de 
s'abstraire de 1' implementation de la structure de stockage des donnees. Cette derniere 
peut aussi bien etre un tableau qu'une table de hachage ou un SGBDR accede via JDBC. 



Mise en oeuvre du refactoring 

Chapitre 4 

Les interfaces sont particulierement utiles dans le cas des tests unitaires. II est possible de 
les utiliser pour creer des classes bouchons (mock objects) permettant de simuler le 
comportement de classes dont depend la classe a tester unitairement (voir le chapitre 5). 

Les risques sont nuls pour la classe dont est extraite l'interface, car sa seule modification 
revient a declarer qu'elle implemente cette derniere. Le remplacement des references a la 
classe par l'interface est peu complexe et consiste essentiellement en un rechercher/ 
remplacer, sauf au moment de la creation de l'instance, ou il faut faire un cast (voir 
I'exemple de mise en ceuvre). Le seul risque ici est de remplacer une reference reposant 
sur des specificites de la classe originelle non reprises par 1' interface. Dans ce cas, la 
compilation detecte immediatement l'anomalie. 

Moyens de detection 

II n'existe pas de moyen de detecter efficacement les cas ou l'extraction d'interface se Justi- 
ne en dehors d'une revue de design. Cependant, il peut etre interessant d'etudier les classes 
ayant un fort couplage afferent, c'est-a-dire ayant de nombreuses classes dependantes, afin 
d'ameliorer la flexibilite du logiciel en decorrelant les services de leur implementation. 

Modalites d'application et tests associes 

La premiere etape est la creation de l'interface. Celle-ci reprend generalement l'ensem- 
ble des methodes publiques de la classe, mais ce n'est pas une obligation. Ensuite, il faut 
que la classe dont est extraite l'interface implemente cette derniere. Pour terminer et 
ameliorer la flexibilite du logiciel, il faut remplacer toutes les references a la classe par 
des references a l'interface lorsque cela est possible. 

Avec Eclipse, l'extraction d'interface est entierement automatisee. L assistant est acces- 
sible via le menu Refactor en selectionnant Extract Interface. Lassistant d'extraction 
d'interface permet de remplacer les references a la classe dont l'interface est extraite par 
cette derniere. 

Du point de vue de la gestion de configuration, une nouvelle ressource, l'interface, doit 
etre ajoutee dans le referentiel. Par ailleurs, toutes les classes utilisant les services de la 
classe dont est extraite l'interface doivent etre modifiees en cas de remplacement des 
references a la classe par des references a l'interface. Cela peut generer un grand nombre 
de revisions s'il s'agit d'une classe avec un fort couplage afferent. 

Le seul test necessaire pour valider cette operation de refactoring est une recompilation. 
Idealement, il faudrait aussi veiller a tester unitairement les cas de chargement dynami- 
que impliquant la classe et dont les problemes ne sont pas detectes au moment de la 
compilation. 

Exemple de mise en oeuvre 

Supposons que, pour les besoins de notre logiciel, chaque classe metier comporte une 
methode renvoi eEtat qui genere un flux XML correspondant au contenu des divers attributs 
de la classe. 
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Pour la classe PersonnePhysique, nous avons : 

import java. uti 1 .Date; 

public class PersonnePhysique { 

private String nom; 
private String prenom; 
private Date dateNaissance; 

//... 

public String renvoieEtatt ) { 

StringBuffer etat = new StringBuffer( ) ; 

etat. append ("<PersonnePhy si que>\n" ) ; 

etat. append ("\t<nom>\n\t\t" ) ; 

etat.append(nom) ; 

etat. append ("\t</nom>") ; 

etat.append("\t<prenom>\n\t\t" ) ; 

etat.append(prenom) ; 

etat. append ("\t</prenom>") ; 

etat.append("\t<dateNaissance>\n\t\t") ; 

etat. append (dateNaissance) ; 

etat. append ("\t</dateNaissance>") ; 

etat. append ("</PersonnePhysique>") ; 

return etat.toStringO ; 
} 
} 

La methode renvoi eEtat etant presente dans toutes les classes metier du logiciel, il peut etre 
interessant de l'extraire sous forme d'interface. Cela permet de recuperer l'etat de tout objet 
metier independamment de sa classe, dans un service de persistance des donnees, par exemple. 

Pour extraire 1' interface, il suffit de selectionner Extract Interface dans le menu Re factor 
apres avoir selectionne la classe dans l'explorateur de package ou l'avoir ouverte dans 
l'editeur de code (voir figure 4.20). 



Extract Interface 



Interface name: | Etat 

W Change references to the class 'PersonnePhysique' into references to the interface (where possible) 
W Declare interface methods as 'public' 
W Decbre interface methods as 'abstract' 



Members to declare in the interface: 



G • getGenreQ 

G e possedeGarconO 
□ e possedeRlleO 



Select All 



Deselect All 



Figure 4.20 

Extraction de V interface Etat 
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Nous appelons 1' interface extraite Etat. Nous selectionnons 1' option permettant de remplacer 
automatiquement les references a la classe par des references a l'interface lorsque cela 
est possible. Nous selectionnons l'option declarant toutes les methodes de l'interface 
comme etant publiques ainsi que l'option declarant les methodes de l'interface comme 
etant abstraites. Cette derniere option permet aux classes abstraites d'implementer cette 
interface sans devoir fournir une implementation de ses methodes. 

Avant d' appliquer le refactoring, nous pouvons previsualiser les modifications qui vont 
etre effectuees en cliquant sur le bouton Preview, comme illustre a la figure 4.21. 



Extract Interface 



Changes to be performed 



G ft 



Person nePh.ysique.1ava - RefactDring/srq/fir/eyrolles/exempleE 



P1& Update type declaration 
0fe create ffe:/Refattorlng/src/fr/eyroles/exeniples/Etat.java 



U] PprsonnpPhysiqisp.jRva 



Origiial Source 



ft Q 



Refactored Source 



lie class PersonnePhysique { 



private String nom; 
private String prenom; 
private Date dateNaissance; 

public String renvoieEtat () { 

StringBuffer etat = new StringBuffer () 
etat . append ( T, <PersonnePhysigue>\n" ) ; 
stat. append ( T, \t.<Tioin>\Ti\t.\t n ) ; 

etat . append (nom) ; 

e La L. append ("\L</num> n ) ; 

etat. append ("VtKprenorroNnNtXt"} ; 

etat . append (prenom) ; 

etat. append ( T, \t</prenom>' T } ; 

etat. append ("\t<dateNai55ance>\n\t\t") 

a-r-zs-t- 3-nnQinri frfSLtoMa-i c: c ■=, r, r o \ - 

« l> 



class Per sonne Physique implements Etat 



ivate 3tring nom," 
ivate String prenom; 
ivate Date dateNaissance; 

slic String renvoieEtat () { 
StringBuffer etat = new StringBuffer (} 
etat . append ( " <Per sonnePhysique>\n" } ; 
etat .append ( n \t.<nnTn>\n\t.\t: n ) ; 
etat . append ( nom) ; 
etaL. append ("\L</noiiL>") ; 
etat . append ( "\t<prenom>\n\t\t") ; 
etat. append {prenom} ; 
etat .append ("\t</ pre nom>") ; 
etat .append (" \t<dateNai5 5ance>\n\t\t" ) 

d-l-ci-r- DnncTiH t ri^t-oH^ ->' cc-jtip q) - 

< >_ 



■ 



•*. 



Figure 4.21 

Liste des modifications liees a 1' extraction de l'interface 
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Nous constatons que l'extraction est correcte puisque l'interface Etat est creee et que la 
classe PersonnePhysi que l'implemente. Nous pouvons done cliquer sur le bouton OK pour 
proceder au refactoring. 

L'interface Etat qui a ete generee est la suivante : 

I public interface Etat { 
public abstract String renvoieEtat( ) ; 

Changement de signature d'une methode 

Le changement de signature d'une methode consiste a modifier un ou plusieurs des 
elements suivants (voir figure 4.22) : 

• nom de la methode ; 

• portee de la methode ; 

• type de la valeur de retour de la methode ; 

• liste des parametres de la methode (nombre de parametres, type des parametres, nom 
des parametres) ; 

• liste des exceptions generees potentiellement par la methode (nombre et type des 



exceptions generees). 



Code originel 



Code refondu 



public class UneClasse { 




public class UneClasse { 


private int uneMethode (String p) |f-- 

II... 
} 

} 


- public double uneMethode (String p1, int p2) {| 
II... 
} 

} 



Figure 4.22 

Changement de signature d'une methode 



Le changement de signature d'une methode peut intervenir dans l'une ou 1' autre des 
situations suivantes : 

• Le nom de la methode ne respecte pas les conventions de nommage ou n'est pas signi- 
ficatif. 

• La portee de la methode n'est pas adaptee. Une portee trop grande, publique, par 
exemple, nuit a 1' encapsulation en devoilant les details d' implementation de la classe. 
Une portee trop courte, privee, par exemple, nuit a la reutilisation. 
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• La valeur de retour ou certains parametres sont inutiles. Leur presence nuit a la 
comprehension du code. II est done utile de les supprimer afin d'alleger la methode. 

• La liste des parametres est trop longue. Une methode ayant plus de quatre ou cinq 
parametres devient rapidement difficile a manipuler. II est done interessant de chercher 
a reduire cette liste, soit en reduisant le perimetre de la methode (voir V extraction de 
methode), soit en encapsulant plusieurs parametres dans un seul parametre plus 
complexe (voir Vexemple de mise en ceuvre). 

• La liste des parametres est trop courte. Par exemple, une methode peut etre rendue plus 
facilement reutilisable en ajoutant quelques parametres supplementaires. 

• Le type d'un parametre ou de la valeur de retour est inadapte. Par exemple, une methode 
effectuant des calculs utilisant des entiers courts peut bloquer sa reutilisation dans des 
contextes ou des nombres plus grands doivent etre manipules. 

Le renommage ayant ete aborde precedemment, nous ne reviendrons pas sur les risques 
associes. La modification de la portee d'une methode est une operation peu risquee 
puisqu'une compilation permet de detecter immediatement les problemes. 

Dans le cas de valeurs de retour ou de parametres inutiles, les risques sont faibles, car les 
traitements effectues par la methode concernee ne sont pas impactes et n'entrainent done 
pas de regression. 

Pour les autres cas de figure, le changement de signature est une operation lourde et 
risquee, qui rompt le contrat liant la methode a ses utilisateurs et necessite de repenser 
leur relation. 

Moyens de detection 

Les parametres inutilises ainsi que les listes de parametres trop longues sont aisement 
detectables par des analyseurs de code tels que Checkstyle. II en va de meme pour les noms 
des methodes ne respectant pas les conventions de nommage formalisables sous forme 
d' expression reguliere ou quantifiables. 

Dans les autres cas, e'est la revue de code qui permet de detecter les methodes necessitant 
un changement de signature. 

Modalites d'application et tests associes 

Une fois la nouvelle signature definie, il faut, le cas echeant, modifier le corps de la 
methode afin de 1' adapter. Ensuite, il faut modifier tous les appels a la methode pour leur 
faire prendre en compte le changement. Cette modification peut aller bien au-dela de la 
simple modification de l'appel et avoir des effets de bord importants, notamment si l'un 
des parametres etait en sortie (objet mutable). 

Eclipse fournit un assistant permettant de modifier aisement la signature d'une methode. 
II est accessible via le menu Refactor en selectionnant Change Method Signature. 
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Du point de vue de la gestion de configuration, l'operation est classique mais peut impliquer 
un grand nombre de ressources pour peu que la methode soit tres utilisee en dehors de sa 
classe proprietaire. En cas de probleme, le retour a la revision anterieure est simple s'il 
n'y a pas eu d'autres changements en parallele. Dans le cas contraire, le retour en arriere 
doit etre gere manuellement afin de ne pas ecraser ces changements. 

Un changement de signature implique la modification des tests unitaires de la methode 
concernee s'ils existent. Si la modification ne concerne que des parametres inutilises, les 
tests peuvent se limiter a une simple recompilation, en prenant soin de verifier qu'il n'y a 
pas d' utilisation de la methode par reflexion. Dans le cas contraire, 1' ideal consiste a 
tester unitairement tous les appelants de maniere a verifier qu'il n'y a pas de regression. 

Exemple de mise en ceuvre 

Supposons une classe Entreprise ayant une methode embaucheSalarie : 

import java. uti 1 .Date; 
public class Entreprise ( 

public void embaucheSalarie(String pNumSecu, String pNom, 
String pPrenom, Date pDateNaiss, String pDirect, 
String pDept, String pPoste, int pTypeCnt, 
int pDureeCnt, Date pDateEmb) { 

} 
public void teste ) { 

embaucheSalarie( "xxxxxxxxxxx" /Martin" , "Didier" , 

new Date (" 10/10/1960" ) ."Informati que", "Etudes", 
"Chef de Projet" ,1 .0.new Date( "01/01/2000" )) ; 
} 
} 

En utilisant Checkstyle, nous constatons que l'analyseur de code detecte les problemes 
illustres a la figure 4.23. 



errors, 2 warnings, infos (Filter matched 2 ot 2 686 itemsj 



Console 



Description 



Resource 



In Folder 



Location | 



&j Maximum Parameters: More than 7 parameters. Entreprise.java Refactortng/src/fr/eyroles/exemples tne B 
& Unused Parameter: Unused pdrdrneler 'uDepl'. Eiilrepr'rse.jdvd RerdLlorLiy/src/rr/eyrofes/exeirrpkis Srje 10 



Figure 4.23 

Problemes detectes avec Checkstyle 
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La configuration par defaut de Checkstyle ne contient pas la regie de detection du code 
inutilise. 

Commencons par l'operation la plus simple, c'est-a-dire la suppression du parametre 
pDept, qui est inutile. Nous lancons 1' assistant de changement de signature en selectionnant 
le nom de la methode dans le code puis en ouvrant le menu Refactor et en selectionnant 
Change Method Signature (voir figure 4.24). 



Change Method Signature 



Access modifier: Return type: 



Method name: 



oubfc -r\ | void 

Parameters | Exceptions | 



| embaucheSalafie 



Type 


Name 


Default value 


1* 


String 


pNumSecu 


- 




Sting 


pNom 


- 


String 


pPrenom 


- 


Date 
Stnng 


pDateNaiss 
pDirection 






String 


pPoste 


- 




int 


pTypeCnt 


j; 


- 



Edit... 



Up 



Method signature preview: 

public void embaucheSalarie (String pNumSecu, 
String pNom, String pPrenom, Date pDateNaiss, 

© Method signature is unchanged. 



Figure 4.24 

Suppression d'un parametre inutile dans la methode embaucheSalarie 



En cliquant sur le bouton Remove, nous supprimons de la liste le parametre pDept qui est 
selectionne. Nous pouvons previsualiser les modifications qui seront effectuees en 
cliquant sur le bouton Preview, comme illustre a la figure 4.25. 

Les modifications etant correctes, nous acceptons l'operation de refactoring en cliquant 
sur le bouton OK. 
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Change Method Signature 



Changes to be performed 



O ft 



B-0# Entreprfee.java - Refactolng/src/fr/eyroles/exemples 
B 00 Enueprbe 

B0 embaucheS3brte(Striig r String, String, Date, String, String, String, ht, int. Date) 

\7]&, change signature 
□ • tcstQ 

P1&, Update reference 



B Entreprise.java 



O ft 



Original Source 



Refactored Source 



employes .put [numSeci], empl nye) 
employes .contains (numSecu) ; 



public void embaucheSalarie (String pNum!E 
String pPrenom, Date pDateNaisf 



empl nyes .put [nmn.Spri], empl r>ye) 
employes .contains (numSecu) ; 



public void embaucheSalarie (String pr 
String pPrenom, Date pDateNc 



^L 



String pDept, String pPoste, 
Date pDateEmb) { 



int 



//. 



public void test [ ) J 

embaucheSalarie ("xxxxxxxxxxx", "Marti 



new Date (" 10/10/1960" ), "Infcy 
1,0, new Date ("01/01/2000")} 




String pPoste,int pTypeCnt, i| 



//. 



public void test (J { 

embaucheSalarie ( "xxxxxxxxxxx" , 



new Date("10/10/1960"), n 3 
0,new Date ("01/01/2000"}) 



Figure 4.25 

Liste des modifications liees a la suppression du parametre inutile 
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Afin de resoudre le probleme du nombre excessif de parametres de la methode embauche- 
Sal ari e, nous realisons un deuxieme changement de signature. L'idee est de regrouper les 
parametres propres a la personne (numero de Securite sociale, nom, prenom, date de 
naissance) au sein d'un unique parametre de type PersonnePhysique (voir figure 4.26). 



Change Method Signature |XI 


Access modifier: Return type: Method name: 


| pubic _rj | void | embaucheSaiarie 




Parameters | Exceptions | 






Type | Name | Default value 


Add 




Edit... 


Sting pDrection 


String pPoste 




irt pTypeCnt 
irt pDureeCnt 


UP | 


Down 


Datp pHatpFmh 








Remove 






Method signature preview: 

public void emJoaucheSalarie (PersonnePhysicjue 
pEmploye, String pDirection, String pPoste, int v 




Preview > 


OK 


Canoe! 







Figure 4.26 

Remplacement de parametres dans la methode embaucheSalarie 



Les quatre premiers parametres de la methode ont ete supprimes au profit du parametre 
pEmploye, cree avec le bouton Add et positionne dans la liste des parametres grace aux 
boutons Up et Down. 

Nous pouvons previsualiser les modifications qui seront effectuees en cliquant sur le 
bouton Preview (voir figure 4.27). 

Nous constatons que le remplacement des quatre parametres par un parametre unique est 
elementaire. Les references aux quatre parametres sont remplacees par un null (voir la 
methode test a la figure 4.27), qui correspond a la valeur par defaut de pEmploye saisie 
dans 1' assistant. Une autre valeur par defaut aurait pu etre une instruction new creant une 
instance de la classe PersonnePhysique. 

L utilisation de 1' assistant ne se suffit pas a elle-meme dans ce cas de figure, et une 
reprise du code manuelle est necessaire. 
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Change Method Signature 



Changes to be performed 

- ^,.-^aatHicj4i.j,i. l .i,mjj,jj.jjj.ii ; ni^j.,M- 

a0© Entrepnse 

g-pl « embauche£abrie(String, String, String, Date, String, String, int, int. Date) 

Pl^, Change signature 
a 4 testQ 

0& Update reference 



& i> 



Hi Entreprise.java 



4> 1? 



Original Source 



Refactored Source 



:yyes . put (numSecu, employe) ; 
nyes . contains (numSecu) ; 



put (numSecu, employe) . 

contains (numSecu) ; 



aid embaucheSalarie (String pNumSecu, String j 
String pPrenom, Date pDateNaiss, String pDi] 
String pPoste,int pTypeCnt, int pDureeCnt, D; 



embaucheSalarie (PersonnePhysigue pEmploye 
ng pPoste, int pTypeCnt, int pDureeCnt, 
pDateEmb) f 



' 



aid testQ { 



acheSalarie ( "xxxxxxxxxxx" , "Martin", "Didier" 
new Date { "10/10/1960"), "Informatique", "CI 
Q,new Date ("01/01/2000")}; 



test { ) ( 



Salarie (null, "Informatigue", "Chef de Proi 
1,0, new Date ("01/01/2000")); 



* 




Figure 4.27 

Liste des modifications liees au remplacement de parametres 

Contrairement a la suppression d'un parametre inutilise, une simple recompilation ne 
suffit pas, et une campagne de tests unitaires est necessaire pour valider la non-regression 
du logiciel. 



Generalisation d'un type 

Le type d'un attribut ou d'une variable locale peut etre remplace soit par un de ses ance- 
tres, soit par une des interfaces qu'il implemente. Cette operation est possible lorsque 
1' utilisation d'un attribut ou d'une variable ne repose que sur les fonctionnalites offertes 
par l'ancetre ou 1' interface remplacant le type originel. 
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La figure 4.28 illustre la generalisation d'un type. 



Code originel 




Code refondu 


public class UneClasse { 




public class UneClasse { 








private Classelmpl unAttribut ; 


private Unelnterface unAttribut ; 


public UneClasse () { 

unAttribut = new ClasseEnfant(); 
} 

} 


public UneClasse () { 

unAttribut = new ClasseEnfant (); 
} 

} 



Figure 4.28 

Generalisation d'un type 



Le remplacement d'un type donne par un de ses ancetres ou par une des interfaces qu'il 
implemente permet de rendre le code plus generique. Dans le cas d'un parametre d'une 
methode, par exemple, 1' utilisation d'un ancetre permet a cette derniere d' accepter les 
objets du type ancetre, mais aussi les objets des types descendants. II en va de meme pour 
l'utilisation d'une interface en lieu et place d'un type donne. Tous les objets qui imple- 
mentent cette interface peuvent etre utilises. L'utilisation des classes ascendantes ou des 
interfaces permet done d'ameliorer la reutilisation. 

Les risques lies a une generalisation de type sont assez faibles, a la condition que vous 
preniez soin de verifier qu'aucune specificite de la classe descendante ou de la classe 
d' implementation a remplacer n'est utilisee. 

Moyens de detection 

Hormis une revue du code manuelle, il n'existe pas de moyens de detection pour ce type 
de refactoring. 

Modalites d'application et tests associes 

La premiere etape consiste a remplacer le type de l'attribut, de la variable locale ou du 
parametre a rendre plus generique par un de ses ancetres ou l'une des interfaces qu'il 
implemente. II suffit ensuite de propager ce changement aux expressions dependant de 
1' element modifie. 

Eclipse fournit un assistant permettant de remplacer aisement les references a une classe 
par des references soit a un de ses ancetres, soit a une des interfaces qu'elle implemente 
si elles sont compatibles. En ce cas, aucune des specificites de la classe dont les referen- 
ces sont a remplacer n'est utilisee. L'assistant est accessible via le menu Refactor 
d' Eclipse en selectionnant Generalize Type. 
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Cet assistant permet de visualiser sous forme arborescente les ancetres ainsi que les inter- 
faces implementees par le type a generaliser. Seuls les ancetres et les interfaces substitua- 
bles au type a generaliser sont selectionnables. Les autres apparaissent en grise. 

Du point de vue de la gestion de configuration, l'operation est assez legere si elle ne 
necessite pas une propagation de la generalisation a une multitude de classes. Dans le cas 
contraire, la lourdeur de l'operation depend du nombre de classes utilisatrices. En cas de 
probleme, le retour arriere ne pose pas de probleme particulier, sauf si un grand nombre 
de classes utilisatrices ont ete modifiees et que d' autres changements ont ete faits en 
parallele. Dans ce cas, l'operation reste simple mais doit etre faite manuellement afin de 
ne pas ecraser les autres changements. 

Pour tester le resultat de l'operation, une recompilation permet de detecter la plupart des 
problemes, d'autant que l'assistant d'Eclipse ne peut remplacer des references que par 
des classes ancetres ou des interfaces strictement compatibles. 

Exemple de mise en ceuvre 

Reprenons l'exemple de la classe Entreprise. Celle-ci possede une table de hachage 
pour stacker l'ensemble des salaries. Cette table est chargee grace a la methode 

chargeListeEmployes : 

import java.util .Hashtable; 
public class Entreprise { 

private Hashtable employes; 

private void chargeListeEmployes( ) { 

employes = new HashtableO; 

employes. put (numSecu, employe) ; 
} 

} 

Afin d'apporter plus de flexibilite a la classe Entreprise en terme de choix de structure de 
donnees, nous pouvons remplacer les references a la table de hachage java.util .Hashta- 
ble par des references al'interface java.util .Map. 

Pour effectuer cette generalisation, nous lancons l'assistant de generalisation en selec- 
tionnant le nom de l'attribut empl oyes dans le code puis en utilisant le menu Refactor et en 
selectionnant Generalize Type (voir figure 4.29). 

Nous constatons que deux generalisations sont possibles : soit avec la classe Di cti onnary, 
soit avec l'interface Map. Nous selectionnons l'interface Map, car la classe Di cti onnary est 
obsolete et ne doit done pas etre utilisee (voir lajavadoc de Sun). 

Nous pouvons previsualiser les modifications qui vont etre introduites dans le code en 
cliquant sur le bouton Preview (voir figure 4.30). 
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Generalize Type 



Choose new type (types shown in gray cannot be selected): 



B-© Hashtable 

O senalizable 
O Cloneable 
a-©* Dictionary 
© Object 



Figure 4.29 

Generalisation de la table de hachage en utilisantl 'interface java.util.Map 



Generalize Type 



Changes to be performed 



O ft 



:-: [Tjtf 1 Entreprise.java - Refactoring/src/fr/eyrotes/exernples 
b@S Entreprtse 
a-0 ° employes 

|7]^i change declared type from Hashtable to Map 



j] Entreprise.java 



O ft 



Original Source 



Refactored Source 



import Java. util. Date; 
import Java. util . Hashtable; 



iinport Java. util. Hashtable ; 



public class Entreprise { 



import Java. util. Map ; 



public class Entreprise 



private Hashtable employes; 



private Map employes ; 



private void chargeListeEmployes () 
String numSecu=""; 
String employe^" ,T ; 

employes = new Hashtable ( ) ; 

employes .put (numSecu, employe) ; 



private void chargeListeEmploye 
String numSecu=""; 
String employe=" TI ; 

employes = new Hashtable (); 

employes. put (numSecu, employe 




* 



v 



Figure 4.30 

Liste des modifications liees a la generalisation 
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Nous constatons que la generalisation a consiste a changer le type de l'attribut empl oyes, qui 
est passe de Hashtabl e a Map. II n'y a eu aucun autre impact sur le code. Les modifications 
etant correctes, nous pouvons effectuer le refactoring en cliquant sur le bouton OK. 

Dans le cas present, une simple recompilation est suffisante pour valider definitivement 
le refactoring. 

Deplacement d'elements 

Le deplacement d'elements consiste a : 

• deplacer une classe ou une interface d'un package a un autre ; 

• deplacer une methode d'une classe ou d'une interface a une autre ; 

• deplacer un attribut d'une classe ou d'une interface a une autre. 

Les deplacements d'elements restructurent la conception ou le code de maniere a les 
rendre plus comprehensibles. 

Dans le cas d'une classe ou d'une interface deplacee d'un package a un autre, il s'agit 
souvent de regrouper au sein d'un meme package des classes ou interfaces ayant une 
me me nature ou une finalite commune. 

Dans le cas d'une methode ou d'un attribut, il s'agit souvent de corriger un probleme de 
conception. 

Le deplacement d'une classe ou d'une interface d'un package a l'autre est tres peu 
risque, car les classes ou les interfaces deplacees ne sont pas modifiees. II faut toutefois 
prendre garde a d'eventuels chargements dynamiques de l'element deplace. 

Le deplacement d'une methode ou d'un attribut est beaucoup plus risque, car il s'agit 
d'une modification de la conception de la classe ou de 1' interface initialement proprietaire. 

Moyens de detection 

Pour le deplacement de classe ou d'interface d'un package a un autre, les metriques 
mesurant le couplage d'un package ou son instabilite peuvent permettre de detecter des 
candidats a ce type de refactoring. 

Pour les autres elements, seule la revue de conception permet de detecter les cas oil des 
deplacements sont judicieux. 

Modalites d'application et tests associes 

Pour le changement de package, 1' operation ne pose pas de probleme particulier, le 
travail le plus fastidieux etant de modifier les importations de la classe ou de 1' interface 
deplacee au sein des classes utilisatrices. 
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Dans les autres cas, il est necessaire d'identifier l'ensemble des references a l'element 
deplace afin de les modifier en consequence. Ces modifications sont plus ou moins 
lourdes en fonction de la portee de l'element deplace (prive, protege ou public) et de 
son couplage. 

Avec Eclipse, les operations de deplacement sont tres simples et sont accessibles en 
selectionnant l'entite a deplacer et en selectionnant Move dans le menu Refactor d'Eclipse. 
L' assistant de deplacement prend en charge la mise a jour des references si elle est auto- 
matisable (deplacement d'une classe d'un package a un autre, par exemple). 

Du point de vue de la gestion de configuration, le deplacement d'une classe ou d'une 
interface d'un package a un autre est plus ou moins bien gere en fonction des outils. Cela 
revient a faire changer de repertoire un fichier. Dans le cas de CVS, il s'agit d'une copie 
a destination du repertoire correspondant au package cible suivie d'une suppression dans 
le repertoire correspondant au package source. Un retour en arriere est dans ce cas un peu 
delicat puisqu'il faut restaurer le fichier supprime, ce qui n'est pas une tache automatique 
avec CVS. 

Par ailleurs, un plus ou moins grand nombre de ressources sont modifiees en fonction du 
couplage de la classe ou de l'interface deplacee, rendant le retour en arriere plus ou 
moins fastidieux. Pour les autres types de deplacement, la gestion de configuration ne 
pose pas de probleme particulier, sauf les desagrements lies a un retour en arriere si un 
grand nombre de ressources ont ete modifiees. 

Le test d'un deplacement d'une classe ou d'une interface d'un package a un autre peut se 
limiter a une simple recompilation, en prenant soin, comme d' habitude, de traiter speci- 
fiquement les cas de chargement dynamique de classe. Pour le deplacement d' autres 
elements, la charge de test depend de la portee de l'element deplace (prive, protege, 
public) et du nombre de classes qui en dependent. Un recours aux tests unitaires est 
necessaire pour verifier que l'operation s'est bien passee. 

Exemple de mise en oeuvre 

Supposons que nous ayons une classe TracesAppl icatives dans un package ne contenant 
que des classes metier du logiciel. Les traces applicatives etant une problematique tech- 
nique, la classe qui les implemente doit etre dans un package prevu a cet effet. 

Pour deplacer la classe TracesAppl icatives avec Eclipse, il suffit de la selectionner dans 
l'explorateur de package et de choisir Move dans le menu Refactor, comme illustre a la 
figure 4.31. 
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Choose destination for 'TracesApplcativesjava': 



B Sr JGenea-IHM-l.O 
H *! JGenea-IHM-2.1 
m-W} lRenRs-Wph-1.n 
EH2? JGenea-Web-m~MLUn"it 
3 £7 Kefactomg 
eSstc 

••fB (default package) 

-fflfr 

■ m fr.eyrotes 

■ fr.eyrotes.exemptes 
-0 fr.eyroles.exem pies, metier 



'.evrofes.exem ptes.technique 



& .settings 
W Update references to the moved elements) 
P update fuly quailed name n non-Java files (forces preview) 

rile name patterns: J 

The patterns are separated by commas C* = any string, ? = any character) 



New.. 



Figure 4.31 

Deplacement de la classe TracesApplicatives 



L' assistant de deplacement propose deux options interessantes : 

• Mettre a jour les references aux elements deplaces (cette option est selectionnee a la 
figure 4.31). C'est une option indispensable au bon fonctionnement de ce type de 
refactoring, qui doit etre systematiquement cochee. 

• Rechercher dans les fichiers autres que du code source les references a 1' element 
deplace (cette option n 'est pas cochee a la figure 4.31). Ici, seules les references plei- 
nement qualifiees, de la forme package. classe. methode, peuvent etre remplacees. La 
recherche peut se limiter a certains types de fichiers. 

Nous selectionnons le repertoire fr.eyrolles.exemples. technique comme package de 
destination pour la classe TracesAppl 1 cati ves puis cliquons sur le bouton OK pour effectuer 
le refactoring. 

La recompilation du projet nous permet de valider le bon deroulement de l'operation. 
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Deplacement d'elements dans le graphe d heritage 

Le deplacement d'elements dans le graphe d' heritage est un cas particulier de la technique 
de refactoring que nous venons de voir. II s'agit de deplacer une methode ou un attribut 
soit d'une classe donnee vers sa classe mere, soit l'inverse. 

Dans le cas oil nous deplacons un element d'une classe mere vers l'une de ses classes filles, 
l'objectif est generalement de rendre la classe mere plus generique. La presence d'elements 
dont la specificite peut etre releguee a une classe fille permet d'alleger le contrat de la classe 
mere vis-a-vis de l'exterieur et facilite ainsi sa reutilisation et sa specialisation. 

Dans le cas ou nous deplacons un element d'une classe fille vers sa classe mere, l'objectif 
est generalement d'augmenter la reutilisation de l'element en question en faisant profiter 
1' ensemble des descendants de la classe mere. 

A l'instar des deplacements de methode ou d'attribut, le deplacement d'elements dans le 
graphe d'heritage est une operation lourde, puisqu'il s'agit d'un changement dans la 
conception du logiciel, et de ce fait risquee. 

Moyens de detection 

L'indice de specialisation d'une classe peut detecter des candidats potentiels. Un indice 
de specialisation tres faible, ou la classe fille n'apporte que peu de specificites par rapport 
a sa classe mere, peut aboutir a un deplacement de tous les attributs et methodes specifiques 
dans la classe mere et a la suppression de la classe fille. 

La methode la plus efficace pour detecter les candidats a ce type de refonte est une revue 
du design. 

Modalites d'application et tests associes 

Les modalites d'application et les tests associes sont identiques au deplacement de 
methode ou d'attribut evoque precedemment. 

Avec Eclipse, deux assistants specifiques sont fournis pour gerer ce type de deplacement. 
Pour transferer une methode ou un attribut de la classe mere vers une de ses filles, il faut 
selectionner Push Down dans le menu Ref actor. Pour effectuer, 1' operation inverse, d'une 
classe fille vers sa classe mere, il faut selectionner Pull Up. 

Exemple de mise en oeuvre 

Reprenons la classe PersonnePhysique. Cette classe est une specialisation de la classe 
Personne, qui possede par ailleurs une deuxieme fille, PersonneMorale. La classe Personne- 
Physique possede une methode pour calculer l'age d'une personne physique. Cette 
methode pouvant etre aussi utile a la classe PersonneMorale, il est interessant de la faire 
remonter au niveau de la classe Personne. 
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Pour cela, nous selectionnons la methode cal cul eAge soit dans l'explorateur de package, 
soit directement dans l'editeur de code puis choisissons Pull Up dans le menu Refactor 

(voir figure 4.32). 



Refactoring 



Pull up 

Select the members to pull up and their new declaring class. 
Fyou select methods, then click "Next" to specify which matching 



*J 



Select destination class: | f r.ey roles.exem pies. Personne 



~H 
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Member 



□ D prenom 

□ a entants 

□ » renvoieEtatO 
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□ ft possedeGarconQ 
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1 members) selected. 



Add Required 



Figure 4.32 

Displacement de la methode calculeAge 



Nous selectionnons dans la combo box la classe de destination Personne et cochons la 
case correspondant a la methode calculeAge. Nous cliquons ensuite sur le bouton Next 
pour previsualiser les modifications (voir figure 4.33). 

Les modifications etant correctes, nous pouvons cliquer sur le bouton Finish afin de la realiser 
effectivement dans le code. 

Dans cet exemple, le deplacement est neutre du point de vue de la classe PersonnePhysique. 
Une recompilation est done suffisante pour valider cette refonte. 
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Pull up 

The following changes are necessary to perform the refactoring. 



*l 



changes to be performed 



o -0- 



onne.iava - Refartorinq/src/fr/eyraDes/exemples 



- 0#i 

0fe Pill Up 

fi Htf 1 HersonnePhysc|ue.]ava - Kefactormg/srqfTr/eyroles/exennples 
ffl-0© Person nePhysique 



•2 Personne.java 



ft 



original biource 



private Date dateNaissance; 

public DaLe yeLDdLeNaissarice () 
return dateNaissance; 



public void setDateNaissance (Da 
dateNaissance = pDateNais5^ 



public String getNom() { 
return nom; 



public void setNom (String pNom) 
nom = pNom; 



Kefactored source 



public void setDateNaissance 

dateNaissance = pDateNa 



public String yeLNoni() { 

return nom; 
} 

public void setNom (String pi 
nom = pNom; 



public int caiculeAge() { 
Date dateDuJour = new D. 
return dateDuJour . getYec 



Figure 4.33 

Liste des modifications liees au deplacement de la methode calculeAge 
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Remplacement d'une variable locale par une expression 

Le remplacement d'une variable locale par une expression est l'operation inverse de 
l'extraction de variable locale. Cela consiste a remplacer des occurrences d'une variable 
locale dans le code de la methode par l'expression ayant servi a 1' initialiser. 

Cette operation peut etre combinee avec une extraction de methode. L'expression est en 
ce cas encapsulee dans une methode, renvoyant la valeur d'initialisation de la variable, et 
les occurrences de la variable locale sont remplacees par un appel a cette methode. 

La figure 4.34 illustre le remplacement d'une variable locale par une expression. 



Code originel 



Code refondu 



public class UneClasse { 

public void uneMethode () { 
int v = expression 1 ; 

resultat = v * expression 2; 

} 



public class UneClasse { 
public void uneMethode () { 



"■■■ i — y — i 

resultat = expression 1 * expression2 



Figure 4.34 

Remplacement d'une variable locale par une expression 



Un tel remplacement se justifie lorsque l'existence de la variable ne semble pas justifiee 
en regard d'une utilisation directe par l'expression ayant servi a son initialisation. 

Les risques sont maitrisables, car il s'agit d'une operation de refactoring strictement 
interne a une methode et done testable de maniere unitaire. 

Moyens de detection 

Seule la revue de code permet de detecter les cas ou cette technique doit etre appliquee. 

Modalites d'application et tests associes 

Avec Eclipse, un assistant permet de gerer automatiquement ce remplacement. II est 
accessible en choisissant Mining dans le menu Refactor. 

Du point de vue de la gestion de configuration, il s'agit d'une nouvelle revision d'une 
ressource (la classe possedant la methode concernee) et ne pose done pas de probleme 
particulier. 

Un simple test unitaire de la methode modifiee permet de s' assurer que le remplacement 
de la variable locale n'a pas de consequence facheuse sur l'execution. En utilisant l'assistant 
d' Eclipse, une simple recompilation est suffisante, car il n'autorise pas le remplacement 
si la variable locale est initialisee plus d'une fois. 
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Exemple de mise en oeuvre 

Reprenons l'exemple de la classe Cylindre apres l'extraction de la methode aireBase. 
Pour rappel, le code source de la classe Cyl 1 ndre est le suivant : 

package fr.eyrol les.exemples; 
public class Cylindre { 
private double rayon; 
private double hauteur; 

public Cyl indre(final double pRayon, final double pHauteur) { 

rayon = pRayon; 

hauteur =pHauteur; 
} 

public double volumeO { 

double aireBase = aireBaseO; 

return aireBase * hauteur; 
} 
public double aireBaseO { 

double aireBase = 3.14 * rayon * rayon; 

return aireBase; 



Nous constatons que les variables locales aireBase n'ont pas grand interet et qu'elles 
pourraient etre remplacees par leur expression d'initialisation. 

Nous allons done remplacer la variable locale aireBase utilisee pour le calcul du volume 
par son expression. Pour cela, nous selectionnons la variable locale de la methode vol ume 
dans l'editeur de code et choisissons Refactor puis Inline, comme illustre a la figure 4.35. 



Inline Local Variable 



4> 



Infrie 1 occurrence ot local variable aireBase ? 



Figure 4.35 

Remplacement d'une variable locale par son expression d'initialisation 



Avant d'effectuer le remplacement effectif, nous pouvons previsualiser le resultat en 
cliquant sur le bouton Preview (voir figure 4.36). 
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Inline Local Variable 



Changes to be performed 



$ 



E0^ Cyfrdre.java - Refactorirtg/src/fr/eyroles/exemples 
E 0© Cyindre 
B-0 « volumeQ 

0fe Remove local variable: aireBase 
Plfe InSne local variable: aireBase 



fJj cylndre.java 



O 



Original Source 

" yi.J.VdL4± UUUIJJ.U ndULeUL, 



public Cylindre (final double pRayon, fina 

rayon = pKayon; 
hauteur =pHauteur; 



Refactored Source 



public double volume [) 



double aireBase = aireBaseO; 
return airpRa.se * hant.eur; 



private double hauteur; 

public Cylindre (final double pRayon,] 
rayon = pRayon; 
hauteur -pHauteur ; 



public double volume ( ) 



return aireDase () * hauteur; 



; 



public double aireBase (} { 

double airpRase = 3-14 * raynn * ra\ 
return aireBase; 



public double aireBase () { 

double aireDase = 3.14 * rayon * 
return aireBase; 



" 



Figure 4.36 

Liste des modifications liees au remplacement de la variable locale 

La meme technique peut etre appliquee a la variable locale ai reBase de la methode ai reBase. 

Pour finir, grace a 1' assistant, une simple recompilation est necessaire pour valider ce 
refactoring. 



Remplacement d'une methode par son corps 

Le remplacement d'une methode par son corps est 1' operation inverse de 1' extraction de 
methode. Cela consiste a remplacer chaque appel de la methode par les expressions qui 
constituent son corps, comme l'illustre la figure 4.37. 

Certaines methodes de tres petite taille n'apportent que peu de valeur ajoutee par rapport 
a P utilisation en direct des expressions qui les composent. C'est typiquement le cas 
lorsqu'une methode privee d'une classe ne comporte que quelques lignes et qu'elle n'est 
appelee que dans un nombre minime d'autres methodes. 
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Code originel 




Code refondu 


public class UneClasse { 






public class UneClasse { 


public int methodeA () { 

return expression 1 ; 
} 








public void methodeB () { 






public void methodeB () { 


resultat = expression 1 * expression 2; 


resultat = methodeA * 
} 

} 


3xpression2; 


} 
} 



Figure 4.37 

Remplacernent d'une methode par son corps 

Cette operation doit etre reservee aux methodes dont la suppression ne nuit pas a la clarte 
du code, voire l'augmente si la signification de la methode n'est pas claire — c'est typi- 
quement le cas dans une tentative de reutilisation extreme, et done inadaptee — , ou 
permet de gagner en performance dans des methodes critiques. 

Les risques sont proportionnels a la complexite de la methode a remplacer (nombre de 
lignes de code et de parametres) et a son couplage afferent. Dans le cas d'une methode 
privee, les risques sont minimes, 1' operation etant strictement interne a une classe. 

Moyens de detection 

Ce type d'operation peut s'averer necessaire apres une analyse de performance. En effet, 
les appels a une methode sont coflteux et peuvent justifier le remplacernent des appels 
aux petites methodes par leur corps. 

Dans tous les cas de figure, une revue de code est necessaire pour identifier les methodes 
devant subir ce type de refonte. 

Modalites d'application et tests associes 

Une fois tous les appels a la methode identifies, il faut remplacer le code de cette derniere 
par son code. Si la methode possede des parametres, il est necessaire de retoucher le code 
arm de 1' adapter au contexte du bloc de code dans lequel le corps de la methode a ete 
insere. Une fois les remplacements termines, il faut supprimer la methode. 

Sous Eclipse, 1' assistant prenant en charge cette operation est le meme que celui qui 
permet le remplacernent d'une variable locale par son expression d'initialisation. En 
fonction de l'element selectionne, l'assistant identifie automatiquement s'il s'agit d'une 
methode, d'une variable locale ou d'une constante. 
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Du point de vue de la gestion de configuration, l'operation est classique. Sa longueur 
depend du nombre de classes impactees par le remplacement. 

Un simple test unitaire des methodes modifiees permet de s' assurer que le remplacement 
de la methode n'a pas eu de consequence nefaste sur l'execution. En utilisant l'assistant 
d' Eclipse, une simple recompilation est suffisante. 

Exemple de mise en ceuvre 

Reprenons le code de la classe Cylindre, duquel nous extrayons la methode aireBase et 
supprimons les variables locales inutiles. Nous obtenons le code suivant : 

package fr.eyrol les.exemples; 
public class Cylindre { 

private double rayon; 

private double hauteur; 

public Cyl indre(final double pRayon, final double pHauteur) { 
rayon = pRayon; 
hauteur =pHauteur; 



public double vol ume( ) { 

return aireBaseO * hauteur; 

} 

public double aireBaseO { 
return 3.14 * rayon * rayon; 



) 



) 



Afin de gagner en performance, nous pouvons remplacer l'appel a la methode aireBase 
par son corps. Pour cela, nous selectionnons l'appel a la methode dans l'editeur de code 
et choisissons Inline dans le menu Refactor. 



Inline Method 



Diine — 

C Al invocations 



I De'ets method declaration 
(• Only the selected invocation 



Figure 4.38 

Remplacement de la methode aireBase par son corps 
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Comme nous voulons conserver la methode ai reBase et optimiser uniquement la methode 
volume, nous selectionnons l'option ne remplacant que l'appel selectionne (voir 
figure 4.38). L' autre option consiste a remplacer tous les appels a la methode et offre la 
possibilite de supprimer cette derniere puisqu'elle n'est plus necessaire. 

En cliquant sur le bouton Preview, nous pouvons previsualiser les modifications introduites 
par cette operation de refactoring, comme illustre a la figure 4.39. 



Changes to be performed 



O 



'- 0^ Cyfndre.java - Refactoring/src/fr/eyro8es/exemples 
E00 Cytndre 
B-|3 e volumeO 

■ 0fe Intne invocation 



|£ Cytndre.java 



O Ti 



Original Source 



ptnmc — crass — i.yi i iilj i- h — \ 

private double rayon; 
private double hauteur; 

public Cylindre tfinal double pRayon, fine 
rayon - pRayon ; 
hduLeiii =pHauLt:ur ; 

} 

public double volume [) { 



Refectored Source 



^-L^SSS — L-Y i \ rn j j h — i 

irate double rayon; 
irate double hauteur ; 

Lie Cylindre (final double pRayon, final dc 
rayon — pRayon; 
hduLeur =pHau.LeLir; 



Lie double volume (} { 



return aireBaseO * hauteur; 



return {3.14 * rayon * rayon) * hauteur 



public double aireBase () { 

return 3.14 * rayon * rayon; 



Lie double aireBase (] { 
return 3.14 * rayon * rayon; 



< 



Figure 4.39 

Liste des lignes modifiees liees an remplacement de l'appel a la methode aireBase par son corps 

Les modifications etant correctes, nous pouvons realiser de maniere effective le refactoring 
en cliquant sur le bouton OK. 



Grace a 1' assistant, une simple recompilation est necessaire pour valider ce refactoring. 
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Remplacement d'une constante par sa valeur litterale 

Le remplacement d'une constante par sa valeur litterale est l'operation inverse de 
l'extraction de constante. Elle consiste a remplacer les acces a une variable ou un attribut 
non modifiable par sa valeur d'initialisation, comme illustre a la figure 4.40. 



Code originel 




Code refondu 


public class UneClasse { 




public class UneClasse { 


private final static int CONSTANTE = 2 ; |~ 




1 

public void'uneMethode () { 

II- 1 
intv2=[2]*v1; 

} 
} 


public void uneMethode () { 

intv2 = CONSTANTE *v1; 
} 

} 



Figure 4.40 

Remplacement d'une constante par sa valeur 

A l'instar de la technique precedente, certaines constantes tres peu utilisees n'apportent 
que peu de valeur ajoutee par rapport a 1'utilisation en direct de leur valeur. II faut cependant 
veiller a ce que le remplacement ne nuise pas a la clarte du code. 

Cette operation de refactoring tres simple ne comporte pas de risque particulier. 



Moyens de detection 

Comme pour la technique precedente, ce type d' operation peut s'averer necessaire apres 
une analyse de performance. En effet, les appels a une constante sont plus couteux que 
1'utilisation directe d'une valeur litterale et peuvent done justifier leur remplacement par 
cette derniere. 

Dans tous les cas de figure, une revue de code est necessaire pour identifier les constantes 
devant subir ce type de refonte. 

Modalites d'application et tests associes 

Une fois tous les acces a la constante identifies, il suffit de les remplacer par la valeur 
litterale. Une fois les remplacements termines, il faut supprimer la constante. 

Sous Eclipse, 1' assistant prenant en charge cette operation est le meme que celui dedie au 
remplacement d'une variable locale par son expression d'initialisation. En fonction de 
l'element selectionne, l'assistant identifie automatiquement s'il s'agit d'une methode, 
d'une variable locale ou d'une constante. 
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Du point de vue de la gestion de configuration, l'operation est classique. Sa longueur 
depend du nombre de classes impactees par le remplacement. 

Normalement, une simple recompilation suffit a identifier tous les problemes. Pour un 
maximum de securite, un simple test unitaire des methodes modifiees permet de s' assurer 
que le remplacement de la constante par sa valeur litterale n'a pas eu de consequence 
nefaste sur 1' execution. 

Exemple de mise en oeuvre 

Reprenons le code de la classe Di sque, dont nous extrayons la constante PI : 

public class Disque { 

private static final double PI = 3.14; 

private double rayon; 

public Disque(final double pRayon) { 

rayon = pRayon; 
} 
public double perimetreO { 

return PI * rayon * 2; 
} 

publ ic double ai re( ) { 
return PI * rayon * rayon; 



Pour des raisons de performances, il est la encore preferable de remplacer la constante 
par sa valeur litterale. Pour cela, nous selectionnons la constante dans l'editeur de code et 
choisissons Refactor et Inline. 



Inline Constant 



Intne- 



(• AI references 

p" Delete constant declaration 

C Only the setected reference 



Figure 4.41 

Remplacement de la constante PI par sa valeur litterale 



Nous remplacons la constante par sa valeur litterale partout dans le code et supprimons la 
declaration de la constante (voir figure 4.41). L' autre option permet de ne remplacer que 
la reference selectionnee. 
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En cliquant sur le bouton Preview, nous pouvons previsualiser les modifications introduites 
par cette operation de refactoring, comme illustre a la figure 4.42. 



Changes to be performed 
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- \Z]& Deque.java - Refactoring/src/fr/eyroles/exempfes 
E 0® Bisque 

p|& Remove constant dedaration 
E » penmetreO 

0S mine constant 
0fe Inlne Constant 



2] Deque.java 



£ ^ 



ongnal source 



pdUK cigt! jli. . ev^urrtJb.KAeiiiyrt;:*, 
public class Disque { 



Kefactored source 



public class Pi a que 



private static final double PI 
private double rayon ; 



3.14; 



private double rayon; 



public uisque (final double pKayon) f 
rayon = pRayon; 

1 

public double perimetry () { 



public Di.sqriFi (final double pRayon} 

rayon = pKayon; 
} 

public double perimetre () { 



return PI * rayon 



return 3.14 * rayon * 2; 



public double airc() 



public double aire() 



return PI * rayon * rayon ; 



return 3,14 * rayon * rayon; 



* 




Figure 4.42 

Liste des modifications liees au remplacement de la constante PI 



Les modifications etant correctes, nous pouvons realiser de maniere effective le refactoring 
en cliquant sur le bouton OK. 

Grace a 1' assistant, une simple recompilation est necessaire pour valider ce refactoring. 
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Conclusion 



Les differentes techniques que nous venons de presenter constituent le minimum neces- 
saire pour effectuer un refactoring. Si elles repondent bien aux besoins de refactoring 
chirurgical, elles s'averent insuffisantes pour des operations plus lourdes. Vous verrez a la 
partie II de cet ouvrage d'autres techniques repondant a ce besoin. 

Nous avons pu constater dans ce chapitre que les tests unitaires etaient indissociables du 
refactoring, meme si les techniques de base sont generalement neutres du point de vue du 
logiciel. Les tests unitaires ainsi que les outils associes sont etudies en detail au chapitre 5. 



5 



Les tests unitaires 
pour le refactoring 



Comme nous l'avons vu au chapitre precedent, les tests unitaires sont un outil essentiel 
pour s'assurer qu'une operation de refactoring ne produit pas de regression dans le logiciel. 

Ce chapitre presente de maniere synthetique deux outils permettant de realiser des tests 
unitaires, le framework JUnit et EasyMock, qui permet de realiser des simulacres 
d'objets, ou mock objects. Ces deux outils permettent de bien saisir les concepts fonda- 
mentaux des tests unitaires. En fonction des technologies du logiciel a tester, ils peuvent 
etre completes par des outils plus specialises. 



Les tests unitaires avec JUnit 

JUnit est un framework Java Open Source cree par Erich Gamma et Kent Beck. II fournit 
un ensemble de fonctionnalites permettant de tester unitairement les composants d'un 
logiciel ecrit en Java. D'autres frameworks suivant la meme philosophie sont disponibles 
pour d'autres langages ou pour des technologies specifiques, comme HTTP. Ils constituent 
la famille des frameworks xUnit. 

Dans les sections suivantes, vous verrez comment manipuler les differents elements fournis 
par le framework pour creer des tests unitaires. 

Les cas de test 

Les cas de test sont une des notions de base de JUnit. II s'agit de regrouper dans une entite 
unique, en l'occurrence une classe Java derivant de junit. framework. TestCase, un ensemble 
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de tests portant sur une classe du logiciel. Chaque test est materialise sous la forme d'une 
methode sans parametre, sans valeur de retour et dont le nom est prefixe convention- 
nellement par test. 

Squelette d'un cas de test 

Supposons que notre logiciel contienne une classe Calc possedant une methode divise 
effectuant une division. Pour tester cette methode, nous pouvons imaginer plusieurs tests : 
une division par 0, une division par 1 et une division par 2. 

Le cas de test correspondant prend la forme suivante avec JUnit : 

import junit.framework.TestCase; 

public class CalcTest extends TestCase { 

public CalcTest(String name) { 

super(name) ; 
} 

public void testDiviseByOt ) { 

} 

public void testDiviseByK ) { 



public void testDiviseBy2( ) { 

} 
} 

Notez la presence d'un constructeur faisant appel directement a celui de l'ancetre de la 
classe. Ce constructeur est necessaire pour utiliser la methode addTest de la classe 
junit. framework. TestSuite, comme nous le verrons plus loin. 

La notion de fixture 

Dans JUnit, la notion de fixture, ou contexte, correspond a un ensemble d'objets utilises 
par les tests d'un cas. Typiquement, un cas est centre sur une classe precise du logiciel. II 
est done possible de definir un attribut ayant ce type et de 1' utiliser dans tous les tests du 
cas. II devient alors une partie du contexte. Le contexte n'est pas partage par les tests, 
chacun d'eux possedant le sien, afin de leur permettre de s'executer independamment les 
uns des autres. 

II est possible de definir deux methodes specifiques pour gerer le contexte : la methode 
setup pour son initialisation et la methode tearDown pour sa destruction, setup est appelee 
avant l'execution et tearDown a la fin de l'execution de chaque methode de test. 
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Ces deux methodes se presentent de la maniere suivante 



public class CalcTest extends TestCase { 
protected void setUpO throws Exception { 

// Creation du contexte 
} 
protected void tearDownO throws Exception 

// Destruction du contexte 
} 



Pour les tests de la classe Calc, nous pouvons creer un attribut de type Calc et utiliser 
setup pour creer une nouvelle instance pour chaque methode de test : 

public class CalcTest extends TestCase { 
private Calc calc; 
protected void setUpO throws Exception { 

cal c = new Calc( ) ; 
} 



Creation de cas de test JUnit sous Eclipse 

Sous Eclipse, la creation de tests unitaires est simplified grace a des assistants. II suffit de 
choisir le menu File puis de selectionner New et Other. La fenetre illustree a la figure 5.1 
s'affiche. 



Select a wizard 

Create a JUnit Test Case 



Wizards: 



£> luva 
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Interface 
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{$ Package 
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Figure 5.1 

Selection de V assistant de creation d'un test unitaire JUnit 
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Pour lancer 1' assistant, il suffit de cliquer sur le dossier Java afin de voir son contenu puis 
de cliquer de la meme maniere sur JUnit et de selectionner JUnit Test Case. En cliquant 
sur le bouton Next, la fenetre illustree a la figure 5.2 s'affiche. 



New JUnit Test Case 
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Figure 5.2 

L'assistant de creation d'un test unitaire JUnit 



Comme vous pouvez le constater, cet assistant demande les informations necessaires 
pour creer un cas de test (dossier source, package a associer au test unitaire, nom de la 
classe du test unitaire, classe mere, etc.) : 

• Cochez la premiere case si le cas de test est auto-executable, c'est-a-dire s'il a une 
methode main. II est possible de specifier le lanceur standard JUnit associe (TestRunner). 
Ces lanceurs sont evoques plus loin dans le chapitre. 

• Cochez les deuxieme ou troisieme cases si les squelettes des methodes setup et tear-Down 
doivent etre crees. 

• Cochez la derniere case si le constructeur de la classe doit etre cree. II faut notamment 
cocher cette case si les tests contenus dans la classe generee doivent etre inclus indivi- 
duellement dans une suite de tests (voir la section suivante). 
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Pour finir, 1' assistant offre la possibilite d'associer le cas de test a une classe a tester via 
le bouton Browse. Concretement, 1' assistant genere pour chaque methode de la classe a 
tester une methode prefixee par test et reprenant le nom de la methode a tester. 

En cliquant sur le bouton Finish, vous lancez la generation du squelette du cas de test par 
1' assistant. 



Les assertions et I'echec 

Dans JUnit, les assertions sont des methodes permettant de comparer une valeur obtenue 
lors du test avec une valeur attendue. Si la comparaison est satisfaisante, le test peut se 
poursuivre. Dans le cas contraire, il a echoue, et un message d'erreur s'affiche dans 
l'outil permettant d'executer les tests unitaires (voir plus loin). 

Les assertions sont heritees de la classe junit.framework.TestCase et leur nom est prefixe 
par assert. 

Pour les booleens, les assertions suivantes sont disponibles : 

IassertEquals (boolean attendu, boolean obtenu) ; 
assertFalse (boolean obtenu) ; 
assertTrue (boolean obtenu) ; 

La premiere assertion permet de verifier l'egalite de la valeur obtenue par rapport a une 
autre variable. Les deux autres testent le booleen obtenu sur les deux valeurs litterales 
possibles, faux ou vrai. 

Pour les objets, les assertions suivantes sont disponibles, quel que soit leur type : 

assertEquals (Object attendu, Object obtenu) ; 
assertSame (Object attendu, Object obtenu) ; 
assertNotSame (Object attendu, Object obtenu) ; 
assertNull (Object obtenu) ; 
assertNotNul 1 (Object obtenu) ; 

assertEquals teste l'egalite de deux objets tandis qu'assertSame teste que attendu et obtenu 
sont un seul et meme objet. Par exemple, deux objets de type java . uti 1 . Date peuvent etre 
egaux, c'est-a-dire contenir la meme date, sans etre pour autant un seul et meme objet. 
assertNotSame verifie que deux objets sont differents. Les deux dernieres assertions 
testent si l'objet obtenu est nul ou non. 

Pour chaque type canonique (int, byte, etc.), une methode assertEquals est definie, 
permettant de tester l'egalite entre une valeur attendue et une valeur obtenue. Dans le cas 
des types canoniques correspondant a des nombres reels (float, double), un parametre 
supplementaire, le delta, est necessaire, car les comparaisons ne peuvent etre tout a fait 
exactes du fait des arrondis. 

II existe une variante pour chaque assertion prenant une chaine de caracteres en premier 
parametre (devant les autres). Cette chaine de caracteres contient le message a afficher si 
le test echoue au moment de son execution. 
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Les assertions ne permettent pas de capter tous les cas d'echec d'un test. Pour ces cas de 
figure, JUnit fournit la methode f ai 1 sous deux variantes : une sans parametre et une avec 
un parametre, permettant de donner le message d'erreur a afficher sous forme de chaine 
de caracteres. L'appel a cette methode entraine l'arret immediat du test en cours et l'affiche 
en erreur dans l'outil d'execution des tests unitaires. 

Reprenons notre exemple CalcTest. II se presente desormais de la maniere suivante : 

public class CalcTest extends TestCase { 
private Calc calc; 
public CalcTest(String name) { 

super(name) ; 
} 

protected void setUpO throws Exception { 

calc = new Calc( ) ; 
} 
public void testDiviseByCK ) ( 

double resultat = calc.divise(lO.O) ; 

// Le resultat attendu est 1'infini 

assertTrue(Double.isInfinite( resultat) ) ; 
} 

public void testDiviseByK ) ( 

double resultat = calc.divise(lO.l) ; 

// Le resultat attendu est 10 Cdelta=0) 

assert Equal s( 10, resul tat ,0) ; 
} 

public void testDiviseBy2( ) ( 

double resultat = calc.divise(10,2) ; 

// Le resultat attendu est 5 (delta=0) 

assert Equals (5, resul tat, 0) ; 
} 



Les suites de tests 

Les cas de test sont generalement tres nombreux pour un logiciel. Ann de simplifier le 
lancement de ces differents tests, il peut etre interessant de les regrouper dans un ou 
plusieurs ensembles permettant de commander leur execution de maniere collective. 

Dans JUnit, de tels ensembles sont appeles des suites de tests. Une suite de tests est definie 
grace alaclasse junit.framework.TestSuite du framework. Pourcela, il suffit de creer une 
instance de cette classe et d'utiliser ses methodes addTest et addTestSuite. 
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La methode addTest 



La methode addTest est utilisee pour ajouter un test unique a la suite, c'est-a-dire une 
methode test particuliere. Par exemple, pour CalcTest, si nous desirons creer une suite 
executant les tests de la division par et par 2, nous ecrivons le code suivant : 

ITestSuite suite = new TestSuiteC'Test de la division par et par 2") ; 
suite. addTest(new CalcTestCtestDiviseByO") ) ; 
suite. addTest(new Cal cTest( "testDiviseBy2") ) ; 

Nous constatons que nous utilisons le constructeur de Cal cTest pour selectionner le test a 
inclure dans la suite, d'ou l'importance de le definir, faute de quoi le cas de test ne peut 
etre inclus dans une suite. 

La methode addTestSuite 

La methode addTestSuite permet d'inclure automatiquement tous les tests contenus dans 
un cas de test. 

Supposons que nous ayons deux cas de test, Cal cTest et DataTest. Le code suivant montre 
comment creer une suite permettant de regrouper la totalite de leurs tests dans une seule 
et meme suite : 

ITestSuite suite = new TestSuiteC'Tests de CalcTest et DataTest"); 
suite. addTestSuite (DataTest .class) ; 
suite. addTestSuite (CalcTest. class) ; 

Encapsulation d'une suite 

Pour executer une suite de tests, il est necessaire de creer une classe qui sera utilisee par 
un des lanceurs de JUnit. Cette classe doit comporter une methode statique sans parame- 
tre appelee suite, renvoyant un objet de type junit. framework. Test (il s'agit d'une inter- 
face implementee notamment par junit. framework. TestSuite). 

Pour notre exemple, cette classe est la suivante : 

import junit .framework. Test; 
import junit .framework. TestSuite; 

publ ic cl ass MaSuite ( 

public static Test suiteO { 

TestSuite suite = new TestSuiteC'Tests..."); 
suite. addTestSuite(DataTest.cl ass) ; 
suite.addTestSuite(CalcTest.cl ass) ; 
return suite; 



Creation d'une suite de tests JUnit sous Eclipse 

Pour creer une suite de tests, il suffit de choisir File puis de selectionner New et Other. 
Dans la fenetre qui s'afhche comme illustre a la figure 5.3, il suffit de selectionner JUnit 
Test Suite et de cliquer sur le bouton Next. 
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Figure 5.3 

Assistant de creation d'une suite de tests 

Grace a cet assistant, vous pouvez selectionner les cas de test a ajouter a la suite (la liste 
des cas disponibles est fournie automatiquement). 

Comme pour la creation d'un cas de test, il est possible de generer automatiquement la 
methode ma i n ainsi que le lanceur standard JUnit associe (voir la section suivante). 

En cliquant sur le bouton Finish, vous lancez la generation de la suite. 



Execution des tests 

Une fois les cas de test et les suites de tests definis, il est necessaire de les executer pour 
verifier le logiciel. 

Les lanceurs standards de JUnit 

Comme explique precedemment, JUnit propose plusieurs lanceurs standards (TestRunners) 
pour executer les cas de test et les suites de tests : 

• lanceur en mode texte ; 

• lanceur en mode graphique reposant sur la bibliotheque AWT ; 

• lanceur en mode graphique reposant sur la bibliotheque Swing. 



Les tests unitaires pour le refactoring 

Chapitre 5 



Pour utiliser le lanceur en mode texte dans un cas de test (ici Cal cTest), il suffit de creer 
une methode main de la maniere suivante : 

I public static void main(String[] args) { 
j unit. text ui .Test Runner. r un (Cal cTest. class) ; 
> 
La classe junit.textui .TestRunner est appelee en lui passant en parametre la classe du cas de 
test (et non une instance) a executer. Cette methode main peut etre ecrite soit directement 
dans la classe du cas de test, comme dans cet exemple, soit dans une classe specifique. 

Si vous executez Cal cTest, vous obtenez le resultat suivant dans la console Java : 



Time: 0,01 
OK (3 tests) 



Ce resultat indique de maniere laconique que les trois tests definis dans CalcTest se sont 
bien executes. 

Pour utiliser le lanceur fonde sur AWT, il faut coder la methode mai n comme ceci : 

public static void main(String[] args) ( 

junit.awtui .Test Runner. run (CalcTest. class) ; 
} 

Si vous executez Cal cTest, la fenetre illustree a la figure 5.4 s'affiche. 
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De la meme maniere, pour utiliser le lanceur fonde sur Swing, il suffit de modifier lege- 
rement le code de la methode main precedent (changement en gras) : 

I public static void main(String[] args) ( 
junit.swingui .Test Runner. run(Cal cTest. class) ; 
> 
Si vous executez Cal cTest, la fenetre illustree a la figure 5.5 s'affiche. 
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Figure 5.5 

Le lanceur fonde sur Swing 



Vous pouvez constater que le lanceur Swing est plus sophistique graphiquement que 
celui fonde sur AWT (presence d'onglets pour visionner les echecs et la hierarchie des 
tests). 

Pour executer une suite de tests, la demarche est similaire. II faut creer une methode mai n 
utilisant la methode suite. Pour la suite Al 1 Tests creee precedemment, elle se presente de 
la maniere suivante : 

I public static void main(String[] args) { 
junit.textui .Test Runner, r un ( All Tests. suiteO) ; 

Comme vous le constatez, le lanceur prend comme parametre le resultat de la methode 
sui te (en gras dans le code) pour connaitre les tests a executer. Cette methode mai n peut etre 
definie soit dans la meme classe que la methode sui te, soit dans une classe specifique. 
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Le lanceur JUnit integre a Eclipse 

Eclipse propose son propre lanceur JUnit parfaitement integre a l'environnement de 
developpement. 

Pour l'utiliser, il n'est pas necessaire de creer une methode main specifique, a la difference 
des lanceurs standards. II suffit de selectionner l'explorateur de package et le fichier du 
cas de test ou de la suite par clic droit et de choisir Run dans le menu contextuel. Parmi 
les choix proposes par ce dernier, il suffit de selectionner JUnit Test. 

Une vue JUnit s'ouvre alors pour vous permettre de consulter le resultat de 1' execution 
des tests. Si tel n'est pas le cas, vous pouvez l'ouvrir en choisissant Window puis Show 
view et Other. Une liste hierarchisee s'affiche, dans laquelle il suffit de selectionner JUnit 
dans le dossier Java et de cliquer sur le bouton OK (voir figure 5.6). 
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Figure 5.6 

La vue JUnit integree a Eclipse 



L'interet de ce lanceur est sa gestion des echecs apres 1' execution des tests. 

Si nous modifions CalcTest de maniere que deux tests echouent (il suffit pour cela de 
mettre une valeur attendue absurde qui ne sera pas respectee par la classe testee), nous 
obtenons dans le lanceur le resultat illustre a la figure 5.7. 

Les echecs (failures) sont indiques par une croix bleue et les succes par une marque 
verte. En cliquant sur un test ayant echoue, la trace d'execution est affichee dans la zone 
Failure Trace. En double -cliquant sur le test, son code source est immediatement affiche 
dans l'editeur de code d'Eclipse. 
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Figure 5.7 

Gestion des echecs dans la vue JUnit d 'Eclipse 

A partir des resultats des tests, le developpeur peut naviguer directement dans son code et 
le corriger dans Eclipse, ce qui n'est pas possible avec les lanceurs standards de JUnit. 



Au-dela de JUnit 



JUnit fournit un socle pour les tests unitaires mais n'a pas vocation a tester unitairement 
des composants reposant sur des technologies complexes, comme J2EE. De ce fait, 
plusieurs frameworks ont ete developpes pour adresser des problematiques techniques 
particulieres. 

Pour tester des applications J2EE, la communaute Open Source propose notamment les 
frameworks suivants : 

• HttpUnit, pour tester les interfaces Web (http://httpunit.sourceforge.net) ; 

• Cactus, pour tester les EJB et les servlets (http://jakarta.apache.org/cactus/) ; 

• StrutsTestCase for JUnit, pour tester les applications Web developpees avec le 
framework MVC Struts (http://strutstestcase.sourceforge.net/). 
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Les simulacres d'objets avec EasyMock 

Le framework JUnit constitute un socle pour realiser des tests unitaires, mais il n'offre 
aucune fonctionnalite specifique pour tester les relations entre les differents objets mani- 
pules lors d'un test. II est de ce fait difficile d'isoler les dysfonctionnements de l'objet 
teste de ceux qu'il manipule. 

Ann de combler ce vide, il est possible d'utiliser des simulacres d'objets (mock objects). 
Comme leur nom l'indique, ces simulacres simulent le comportement d'objets reels. II 
leur suffit pour cela d'heriter de la classe ou de l'interface de l'objet reel et de surcharger 
chaque methode publique. Le comportement de chaque methode est ainsi redefini selon 
un scenario concu specifiquement pour le test unitaire et done parfaitement maitrise. 

Par exemple, si nous testons un objet faisant appel a un autre objet accedant a une base de 
donnees, nous pouvons remplacer ce dernier par un simulacre. Ce simulacre ne se 
connectera pas a la base de donnees mais renverra des donnees statiques specialement 
definies pour le test unitaire. Nous isolons de la sorte l'objet teste des contingences speci- 
fiques de l'objet accedant a la base de donnees. 

Plusieurs frameworks permettent de creer ces simulacres. Pour les besoins de l'ouvrage, 
nous avons choisi EasyMock, qui est l'un des plus simples d'utilisation. 

Cette section n'introduit que les fonctionnalites principales d'EasyMock. Pour plus 
d' informations, consultez le site Web dedie, a l'adresse http://www.easymock.org. 



Les simulacres bouchons 

Les simulacres les plus simples sont les bouchons, ou stubs. lis consistent a definir, a 
partir d'une interface ou d'une classe du logiciel, une implementation simulant le 
comportement d'un objet reel. Cette simulation consiste generalement, pour chaque 
methode implementee, a renvoyer des valeurs predefinies. 

Par exemple, supposons que nous desirions tester une classe appelee ConsommateurJeton, 
dont le code est reproduit ci-dessous : 

package f r . eyrol 1 es .exempl es .mock; 

public class ConsommateurJeton implements Runnable { 

private String nom; 

private IGestionnaireJeton manager; 

public ConsommateurJetonCString pNom.IGestionnai reJeton pMngr){ 

nom = pNom; 

manager = pMngr; 
} 

publ ic void runt ) { 

System. out. printlnC'Lancement de "+ nom + 
" : le gestionnaire de jeton a " + 
manager. getNbreJetonst ) + " jeton(s)."); 
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Jeton jeton = manager. prendJeton(nom) ; 

System. out. println(nom + " a le jeton " + jeton. getNumerot )) ; 

manage r.rendJeton(nom, jeton) ; 

try { 

Thread. sleep(lOO); 
} 
catchdnterruptedException e) { 

System. out .println(e) ; 



jeton = manager. prendJeton(nom) ; 
System. out. print! n(nom + " a le jeton 
manage r.rendJeton(nom, jeton) ; 



+ jeton. getNumero( )) ; 



) 

Cette classe comporte une methode run dont l'execution necessite un jeton pour afficher 
des donnees sur la console Java. Ce jeton est fourni par un gestionnaire, dont l'interface 
est la suivante : 

package f r.eyrol les.exemples.mock; 
public interface IGestionnaireJeton { 

public Jeton prendJeton(String pConsommateur) ; 

public void rendJeton(String pConsommateur, Jeton pjeton); 

public int getNbreJetons( ) ; 
} 

Les methodes prendJeton et rendJeton possedent toutes deux un parametre pConsommateur, 
qui leur fournit le nom du consommateur, un meme gestionnaire etant partage par 
plusieurs consommateurs. 

La classe Jeton est quant a elle tres elementaire puisque le jeton ne vehicule aucun 
comportement particulier : 

package f r.eyrol les.exemples.mock; 
public class Jeton { 
private int numero; 

public Jetontint pNumero) { 

numero = pNumero; 
} 

public int getNumeroO { 
return numero; 



public void setNumeroO'nt pNumero) 

numero = pNumero; 
} 
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Pour tester la classe ConsommateurJeton independamment de 1' implementation du gestionnaire 
de jeton, nous creons un simulacre bouchon simulant le fonctionnement d'un veritable 
gestionnaire de jeton. 

Bien entendu, comme il s'agit d'une simulation, le simulacre est necessairement plus 
simple que le veritable gestionnaire de jeton. Sinon, quel serait l'interet de le simuler ? 

Avec EasyMock, la creation d'un simulacre s'effectue dans le cadre d'un cas de test (au 
sens JUnit). 

Avant de programmer, definissons rapidement le comportement de notre simulacre pour 
chaque methode a implementer : 

• Pour la methode getNbreJetons, censee renvoyer le nombre de jetons disponibles aupres 
du gestionnaire, le simulacre renvoie systematiquement 1 (toute valeur superieure a 
conviendrait). 

• Pour la methode prendJeton, censee renvoyer un jeton, le simulacre renvoie une 
nouvelle instance de la classe Jeton avec le meme numero. 

• Pour la methode rendJeton, censee remettre le jeton dans la liste des jetons disponibles 
aupres du gestionnaire, aucun comportement n'est defini puisque nous ne gerons pas 
les jetons dans le simulacre. 

Maintenant que nous avons defini le comportement du simulacre, nous pouvons le definir 
au sein d'un cas de test : 

package f r . eyrol 1 es . exempl es .mock; 

import junit.framework.TestCase; 
import org.easymock.MockControl ; 

public class ConsoJetonBouchonTest extends TestCase { 

private ConsommateurJeton consommateur; 
private IGestionnaireJeton manager; 
private MockControl control; 
private Jeton jeton; 

protected void setUpO throws Exception { 
// Creation du simulacre 

control = MockControl .createControl (IGestionnai reJeton. class) ; 
manager = (IGestionnaireJeton) control .getMock( ) ; 
jeton = new Jeton(l) ; 
manager. get NbreJetonsO ; 
control . setDefaul t Return Val ue(l) ; 
manager. prend Jeton ( "Observe") ; 
control .setDefaul tReturnVal ue( jeton) ; 
manager. rendJeton ( "Observe" .jeton) ; 
control .setDefaul tVoidCa 11 able ( ) ; 
// Creation de 1 'instance a tester 
consommateur = new ConsommateurJeton ( "Observe" , manager); 
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public void testConsommateur( ) { 

control . replay ( ) ; 

consommateur.runt ) ; 

control .verify( ) ; 
} 

protected void tearDownO throws Exception { 

control . reset( ) ; 
} 
} 

Nous avons redefini la methode setup (heritee de TestCase) afin de creer le simulacre et 
l'instance de l'objet a tester. La creation du simulacre consiste a creer une instance 
d'objet implementant l'interface IGestionnaireJeton. Cette operation s'effectue en deux 
temps : 

1. Creation d'un controleur (control) en utilisant la methode createControl de la classe 
MockControl. Cette methode prend en parametre l'interface que le simulacre doit 
implementer. 

2. Appel de la methode getMock de l'objet control afin d'obtenir le simulacre propre- 
ment dit. 

Pour que le simulacre fonctionne, il est necessaire de specifier le comportement de 
chacune de ses methodes publiques. II suffit pour cela de les appeler une a une. Chaque 
appel doit etre suivi d'un appel a une methode setDef aul tReturnVal ue du controleur pour 
specifier la valeur de retour de la methode venant d'etre appelee. Si la methode n'a pas de 
valeur de retour (void), il suffit d'appeler setDefaultVoidCallable. 

La methode setup se termine par la creation d'une instance de ConsommateurJeton (sujet 
du test). 

La methode tearDown est elle aussi redefinie afin qu'elle reinitialise le simulacre a la fin 
du test via la methode reset du controleur. 

Le test implemente dans la methode testConsommateur commence par appeler la methode 
repl ay du controleur, indiquant a ce dernier que la phase d'enregistrement du comporte- 
ment du simulacre est terminee et que le test commence. La methode run est ensuite 
appelee, suivie d'un appel a la methode verify du controleur afin de verifier que le simu- 
lacre a ete correctement utilise (un exemple de mauvaise utilisation serait d'appeler une 
methode dont le comportement n'a pas ete specifie). 

Si nous executons le cas de test, nous obtenons le resultat suivant dans la console Java 
(produit par la classe ConsommateurJeton) : 



Lancement 


de Bouchonne : 


le gestionnaire de jeton a 1 jeton(s). 


Bouchonne 


a le jeton 1 




Bouchonne 


a le jeton 1 
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Nous constatons que l'utilisation du simulacre est totalement transparente pour la classe 
ConsommateurJeton. Par ailleurs, l'executeur du cas de test ne signale aucune erreur, comme 
l'illustre la figure 5.8. 
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Figure 5.8 

Execution du cas de test avec bouchon 



Signalons pour terminer qu'il est possible de definir plusieurs comportements differents 
pour une meme methode en fonction de la valeur des parametres qui lui sont passes : 

si mul acre. dit Bon jour ("Jean") ; 

control . setDefaul t Ret urn Value ( "Bon jour X") ; 

control . setReturnValueC Bon jour Jean") ; 

si mul acre. dit Bon jour ("Phil ippe") ; 

control .setReturnVal ue( "Bon jour Phil ippe") ; 

Si nous appelons la methode bonjour dans uncas detest avec Jean, Philippe puis Frangois, 
nous obtenons le resultat suivant : 



Bonjour 


Jean 




Bonjour 


Phil 


ppe 


Bonjour 


X 
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Nous constatons que setDefaultReturnValue definit la valeur par defaut de la methode 
alors que setReturnVal ue associe la valeur de retour aux valeurs des parametres passes a 
la methode. 

Si une methode dont le comportement n'est pas defini est appelee, une erreur est generee. 
II est possible d'affecter un comportement par defaut a chaque methode en utilisant la 
methode createNiceControl du controleur. Son interet est toutefois limite, car ce compor- 
tement consiste a renvoyer 0, f al se ou nul 1 comme valeur de retour. 

Les simulacres avec contraintes 

Le framework EasyMock permet d'aller plus loin dans les tests d'une classe en specifiant la 
facon dont les methodes du simulacre doivent etre utilisees. Au-dela de la simple definition 
de methodes bouchons, il est possible de definir des contraintes sur la facon dont elles sont 
utilisees, a savoir le nombre de fois ou elles sont appelees et l'ordre dans lequel elles le sont. 

Definition du nombre d'appels 

EasyMock permet de specifier pour chaque methode bouchon des attentes en terme de 
nombre d'appels. La maniere la plus simple de definir cette contrainte est de ne pas defi- 
nir de valeur par defaut. 

En effet, EasyMock s' attend a ce qu'une methode soit appelee une seule fois pour une 
combinaison de parametres donnee. Dans l'exemple precedent, si nous appelons la methode 
ditBonjour avec le parametre Jean au lieu de Frangois, nous obtenons le resultat suivant : 



Bonjour Jean 
Bonjour Philippe 
Bonjour X 



Si nous supprimons l'appel a setDef aul tReturnVal ue, une erreur d'execution est generee, 
comme illustre a la figure 5.9. 



= Faiure Trace 



'; junLframework.AsserBonFaledError: 

Unexpected method cal ditBonjour(" Francois"): 
ditEtonjour("Frangois"): expected: Q, actual: 1 
= at org .easy mock.internal. ObjectMethodsRIte r. in voke(0 bjectMethod sFJter.java :44) 
= at org .easy mock.ctassextension . MockCtassControl$2.iritercept(MockClassControl.java: 67) 
= atfr.eyroles.exemples. mock.GestionnaireJ etonJSEnhancerByCGLB$J4d22b328.(titEionjour(<generated>) 
= atfr.eyroles.exemples. mock.ConsoJ etonBouchonTest.testConsommateu r(ConsoJetonBouchonTest .Java :45) 
= at sun.rertect.MativeMethodAccessorImpl,invokeQ{Nafn/e Method) 
= at su n . reflect.NativeMethod Accessorlm pi. in voke(NativeMethodAccessorIrn pl.java : 39) 
= at su n . reflect.DelegatingMethod Accessorlm plJnuoke(De(egatHig MethcbdAccessorlmpl.java : 2 5) 



Figure 5.9 

Appel inattendu a la methode ditBonjour 
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L'erreur affichee indique que l'appel a la methode ditBonjour("Frangois") est inattendu 
(unexpected). Le nombre d'appel de ce type attendu (expected) et effectif (actual) est 
precise. En l'occurrence, le nombre attendu d'appel est 0, et le nombre effectif 1. 

De meme, si la methode ditBonjour n'est pas appelee avec le parametre Philippe, une 
erreur est generee puisque EasyMock s' attend a ce qu'elle soit appelee de cette maniere. 

Pour definir un nombre exact de fois oil une methode doit etre appelee, il faut specifier 
celui-ci en deuxieme parametre de la methode setReturnValue et en premier de la 
methode setVoidCallable du controleur. Ainsi, si nous voulons que la methode bonjour 
soit appelee deux fois avec Jean et une seule fois avec Philippe, nous modifions notre 
code de la maniere suivante : 

si mul acre. ditBonjour ("Jean") ; 

control .setDefaul tReturnVal ue( "Bonjour X") , 

control .setReturnVal ue( "Bonjour Jean", 2) ; 

si mul acre. ditBonjour ("Phil ippe") ; 

control .setReturnVal ue( "Bonjour Phil ippe") ; 

Si nous executons notre test avec ce nouveau simulacre, nous obtenons le resultat 
suivant : 



Bonjour Jean 
Bonjour Philippe 
Bonjour Jean 



Si nous retablissons la valeur par defaut (ligne barree) et que nous appelions trois fois au 
lieu de deux la methode ditBonjour avec le parametre Jean, nous obtenons le resultat 
suivant : 



Bonjour 


Jean 




Bonjour 


Phil 


ppe 


Bonjour 


Jean 




Bonjour 


X 





Ce nombre fixe pouvant etre tres contraignant, il est possible de specifier un intervalle 
dans lequel doit se trouver le nombre d'appel effectif. Les bornes minimale et maximale 
sont specifiers respectivement en deuxieme et troisieme parametres de setReturnValue 
(premier et deuxieme parametres de setVoidCal 1 abl e). 

Pour la methode ditBonjour, nous pouvons specifier qu' elle peut etre appelee entre une et 
trois fois avec le parametre Jean de la maniere suivante : 

I si mul acre. ditBonjour ("Jean" ) ; 
control .setReturnVal ue( "Bonjour Jean ",1,3) ; 
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II est possible de definir deux types d'intervalles non bornes pour le maximum : 

s i mul ac re. dit Bon jour ("Jean") ; 

control . setReturnVal ue(" Bon jour Jean".MockControl .ZER0_0R_C0NTR0L) ; 

si mul acre .di t Bon jour ( "Phi 1 i ppe" ) ; 

control .setReturnValueC'Bonjour Phil ippe".MockControl .0NE_0R_C0NTR0L) ; 

Ici, la methode ditBonjour avec Jean peut etre appelee zero ou plusieurs fois. Avec 
Phi 1 i ppe, elle doit etre appelee une ou plusieurs fois. 



Definition de I'ordre d'appel des methodes 

L'ordre d'appel des methodes est important pour tester la facon dont un objet manipule 
les autres. Avec EasyMock, nous pouvons definir l'ordre dans lequel les methodes d'un 
simulacre doivent etre appelees. 

Dans notre premier exemple, la methode prendJeton doit etre systematiquement appelee par 
ConsommateurJeton avant la methode rendJeton. La methode createControl du controleur 
ne prend pas en compte l'ordre d'appel des methodes du simulacre. 

Nous definissons la methode setup de ConsoJetonBouchonTest de la maniere suivante : 

protected void setUpO throws Exception { 

// Creation du simulacre 

control = MockControl .createControl (IGestionnai reJeton. class) ; 

manager = ( IGestionnaireJeton) control .getMock( ) ; 

jeton = new Jeton(l) ; 

manager. getNbreJetons( ) ; 

control .setReturnVal ue(l) ; 

manager. prend Jeton ( "Observe" ) ; 

control .setReturnVal ue( jeton, 2) ; 

manager. rend Jeton ("Observe" , jeton) ; 

control .setVoidCallable(2); 

// Creation de 1 'instance a tester 

consommateur = new ConsommateurJetonC'Observe" , manager); 
} 

Si nous utilisons ce cas de test, aucune erreur d' utilisation du simulacre n'est signalee. 
En effet, la methode run de consommateur est conforme aux contraintes specifiees dans le 
simulacre. 

Pour tenir compte de l'ordre, il suffit de remplacer la methode createControl du contro- 
leur par createStri ctControl . Si nous effectuons cette modification sur le code precedent 
sans autre modification, nous obtenons le resultat illustre a la figure 5.10. 

Nous constatons que l'erreur indique l'appel inattendu (unexpected) de la methode rend- 
Jeton telle qu'attendue par EasyMock. 
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= Fatire Trace 



' I ]unfcframework.AssertioriFailedError: 
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Figure 5.10 

Resultat du non-respect de I'ordre d'appel 



Pour definir I'ordre d'appel de deux appels successifs a prend Jeton et rendJeton, nous devons 
modifier la methode setup de la maniere suivante : 

protected void setllpO throws Exception { 

// Creation du simulacre 

control = 

MockControl .createStrictControl ( I Gestionna ire Jeton. class) ; 

manager = ( IGestionnaireJeton) control .getMock( ) ; 

jeton = new Jeton(l) ; 

manager. getNbreJetons( ) ; 

control .setReturnValue(l) ; 

manager. prend Jeton ( "Observe" ) ; 

control . set Ret urnValue( jeton) ; 

manager. rendJeton ("Observe" , jeton) ; 

control .setVoidCal 1 ablet ) ; 

manager. prend Jeton ( "Observe" ) ; 

control . set Ret urnValue( jeton) ; 

manager. rendJeton ("Observe" , jeton) ; 

control .setVoidCal 1 ablet ) ; 

// Creation de 1 'instance a tester 

consommateur = new ConsommateurJetonC'Observe" , manager); 
} 

En executant le cas de test avec ce nouveau simulacre, aucune erreur n'est relevee. 

L'ordre d'appel des methodes est defini par la sequence de leur appel pour la definition 
du simulacre. Cela explique pourquoi la version precedente de setup a echoue : quand 
nous specifions qu'une methode doit etre appelee deux fois, cela signifie pour EasyMock 
que cela doit se faire successivement. 
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Les simulacres de classes 

Comme vous avez pu le constater, les simulacres que nous avons definis sont tous issus 
d'interfaces. Par defaut, EasyMock ne permet pas de creer des simulacres a partir de classes. 
II est toutefois possible d'utiliser la bibliotheque CGLIB pour creer de tels simulacres. 
II s'agit d'un fichier JAR a ajouter dans la variable d'environnement CLASSPATH. 

Du point de vue du code, il faut utiliser la classe org. easymock. class extension. MockCl ass - 
Control en lieu et place de org. easymock. MockControl pour la creation du controleur. Par 
contre, le controleur reste du type MockControl . 

Si nous reprenons notre exemple, le cas de test devient le suivant (les modifications sont 
en gras) : 

package fr.eyrol les .exemples.mock; 

import junit.framework.TestCase; 
import org. easymock. MockControl ; 
import org. easymock. classextension.MockClassControl : 

public class ConsoJetonBouchonTest extends TestCase { 

private ConsommateurJeton consommateur; 

private IGestionnaireJeton manager; 

private MockControl control; 

private Jeton jeton; 

protected void setUpO throws Exception { 

// Creation du simulacre 

control = 
MockCl assControl .createControl (Gestionnai reJeton. class) ; 

manager = (IGestionnaireJeton) control .getMock( ) ; 



Autres considerations sur les simulacres 

Pour terminer cette section consacree aux simulacres d'objets, il nous semble important 
d'insister sur deux points fondamentaux pour bien utiliser les simulacres : 

• Un cas de test portant sur un objet utilisant des simulacres ne doit pas tester ces derniers. 
L'objectif des simulacres est non pas d'etre testes, mais d'isoler un objet des contin- 
gences exterieures afin de faciliter sa verification. 

• Un simulacre doit etre concu de maniere a produire des donnees susceptibles de 
generer des erreurs dans l'objet a tester. Comme nous l'avons deja indique, le passage 
des tests ne demontre pas qu'un objet fonctionne correctement, mais demontre qu'il a 
su passer les tests. 

EasyMock repond a des besoins simples en terme de simulacres. Pour des besoins plus 
complexes, vous pouvez utiliser des frameworks plus puissants, mais aussi plus difficiles 
a utiliser, comme jMock (http://www.jmock.org). 
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Analyse de couverture avec EMMA 

L'objectif des tests unitaires est de s'assurer que le comportement d'un composant, sujet 
du test, repond a ses specifications. Lors de l'ecriture d'un test unitaire, il n'est pas 
toujours aise de s'assurer que tous les cas de figure sont bien abordes par les tests unitaires. 
L' analyse de couverture permet, dans une certaine mesure, de s'assurer que le composant 
a ete suffisamment teste, comme nous l'avons montre au chapitre 3. 

Pour realiser 1' analyse de couverture d'un test, nous utilisons dans cet ouvrage EMMA. 

Mise en place de EMMA 

Vous trouverez en annexe les informations necessaires pour telecharger EMMA. 

La distribution comprend les fichiers emma.jar, necessaire a l'execution d'EMMA, et 
emma_ant.jar, contenant la definition des taches Ant. 

Pour utiliser EMMA dans vos projets, il suffit d'inclure ces deux fichiers JAR dans votre 
variable d'environnement CLASSPATH. Grace aux taches Ant d'EMMA, 1' instrumentation 
et la generation de rapports d' analyse sont faciles a mettre en oeuvre. Nous utilisons ici 
1' implementation Ant d' Eclipse pour nos exemples. 



Important 

Si le code a analyser est execute dans un serveur d'applications ou un moteur de servlets/JSP, il est 
necessaire de copier le fichier emma.jar dans le repertoire lib\ext du JRE utilise. 



Le script Ant suivant propose une cible pour 1' instrumentation (i nstrumentati on) du code 
et une autre pour la generation du rapport (rapport) : 

<?xml version="1.0" encoding="UTF-8" ?> 
<project name="AnaCouverture" defaul t="instrumentation" 
basedir=" . "> 

<property name="build.di r" location="bin"/> 

<property name="src.di r" location="src"/> 

<property name="coverage.dir" location="coverage'7> 

<path id="emma.l ib"> 

<fileset di r="${basedi r}" incl udes="emma*. jar"/> 
</path> 

<taskdef resource="emma_ant. properties" classpathref="emma.l ib"/> 

<target name=" instrumentation'^ 

<emma> 

<instr instrpath="${build.dir}" mode="overwrite"/> 

</emma> 
</target> 
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<target name="rapport"> 
<emma> 

<report sourcepath="${src.dir}"> 

<infileset dir="${basedir}" includes="*.em,*.ec"/> 
<html outf i le="${ coverage. dir} /coverage. html "/> 
</report> 
</emma> 
</target> 
</project> 

Le script definit les trois proprietes suivantes : 

• basedir, qui specifie le repertoire de base du prqjet dans lequel sont enregistres les 
fichiers JAR. 

• bui 1 d . di r, qui specifie le repertoire dans lequel sont stockees les classes Java compilees 
a instrumenter. 

• coverage. dir, qui specifie le repertoire dans lequel le rapport doit etre genere. 

Pour utiliser la tache Ant emma, il est necessaire d'inclure les JAR d'EMMA avec la tache 
Ant path puis d'indiquer le fichier de definition avec la tache Ant taskdef . 



Instrumentation du code 

Pour instrumenter le code, il faut utiliser la tache Ant suivante : 

|<emma> 
<instr instrpath="$(build.di r}" mode="overwrite"/> 
</emma> 

Cette tache instrumente les classes Java compilees qui se trouvent dans le repertoire 
specifie par le parametre instrpath. Dans notre exemple, il s'agit d'une variable Ant 
appelee bui 1 d . di r. Le parametre mode specifie la facon dont sont creees les classes instru- 
mentees. Dans notre exemple, elles remplacent leurs classes d'origine. 



Important 

EMMA a besoin que les classes Java a instrumenter soient compilees avec les informations de debogage. 
Si vous utilisez javac, il vous faut recourir a I'option -g. Si vous utilisez Eclipse, ouvrez Window, Preferences 
puis I'onglet Compliance and Classfiles de la rubrique Java et Compiler des preferences, et assurez-vous 
que les cases suivantes sont cochees : Add variable attributes to generated class files, Add line number 
attributes to generated class files et Add source file name to generated class file. 



Pour executer la cible instrumentation sous Eclipse, il faut selectionner par clic droit 
le fichier build.xml dans la vue Package Explorer et choisir Run\Run Ant Build dans le 
menu contextuel. 
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Si vous executez la cible instrumentation du script Ant donne precedemment, la console 
Java doit afficher les informations suivantes (donnees a titre indicatif) : 



Buildfile: C:\Ecl ipse3\workspace\Refactoring\bui ld.xml 

instrumentation: 

[instr] processing instrumentation path ... 
[instr] instrumentation path processed in 441 ms 
[instr] [53 class(es) instrumented, resource(s) copied] 
[instr] metadata merged into [C:\Eclipse3\workspace\Refactoring\coverage.em] 
*{in 90 ms} 

BUILD SUCCESSFUL 

Total time: 1 second 



Vous constatez que 53 classes sont instrumentees (il s'agit des classes se trouvant dans le 
repertoire build.dir). Les informations necessaires a EMMA sont enregistrees dans le 
fichier coverage.em. 



Important 

Veillez a executer le script Ant dans le meme JRE qu'Eclipse, faute de quoi il est impossible d'acceder aux 
taches et proprietes Ant specifiques de cet environnement de developpement. Pour le configurer, selec- 
tionnez par die droit le fichier build.xml dans la vue Package Explorer, et choisissez Run\Run Ant build 
dans le menu contextuel. Dans I'onglet JRE, selectionnez Run in the same JRE as the Workspace, et 
cliquez sur le bouton Apply. 



Une fois les classes instrumentees, il vous suffit d'executer les tests unitaires. EMMA 
collecte toutes les informations sur les lignes de code executees. 

L' execution d'un code instruments est visible dans la console Java : 



EMMA: collecting runtime coverage data ... 




EMMA: runtime coverage data merged into [C:\Ecl 


ipse3\workspace\Refactoring\ 


*»coverage.ec] (in 151 ms} 





La premiere ligne est affichee au lancement du code et la seconde quand 1' execution se 
termine. Cette derniere precise que les informations d' execution sont stockees dans le 
fichier coverage.ee. 



Remarque 

Pour supprimer 1'instrumentation des classes, il suffit de recompiler le projet. 
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Generation du rapport 

Pour generer le rapport, il faut utiliser la tache Ant suivante : 

<emma> 
< report sourcepath="$(src.di r}"> 
<infileset dir="${basedir}" includes="*.em,*.ec"/> 
<html outf ile="$ {coverage. dir} /coverage. html "/> 
</report> 
</emma> 

Cette tache recupere les informations stockees dans les fichiers coverage.em et cove- 
rage.ec (voir le tag i nfi 1 esetj enregistres dans le repertoire basedir et genere un rapport 
HTML appele coverage.html dans le repertoire specifie dans la propriete coverage. di r. 
II est necessaire de specifier dans le tag report le repertoire contenant le code source via 
le parametre sourcepath. 

Pour executer cette cible avec Eclipse, il faut selectionner le fichier build.xml dans la vue 
Package Explorer, utiliser le menu contextuel Run Ant build..., cocher la cible rapport 
dans l'onglet Targets et cliquer sur le bouton Run. La cible instrumentation doit etre 
decochee. 

L' execution de cette cible affiche les informations suivantes dans la console Java : 



Buildfile: C:\Eclipse3\workspace\Refactoring\build.xml 
rapport: 

[report] processing input files ... 

[report] 2 file(s) read and merged in 60 ms 

[report] writing [html] report to [C:\Eclipse3\workspace\Refactoring\coverage 

**\coverage.html ] ... 
BUILD SUCCESSFUL 
Total time: 2 seconds 



Nous pouvons constater qu'un fichier coverage.html est cree dans le repertoire cove- 
rage. Ce fichier liste les packages traites par EMMA avec leurs statistiques generales. II 
suffit de cliquer sur les liens pour acceder aux informations plus detaillees. 

Si nous executons la cible rapport apres avoir execute le cas de test Cal cTest, nous obtenons le 
resultat illustre a la figure 5.11. 

Nous constatons que Cal cTest assure une couverture a 100 % de Cal c. Notre test unitaire 
est done optimal. Si des lignes de code n'avaient pas ete executees, elles apparaitraient en 
rouge dans le listing. 
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COVERAGE SUMMARY FOR SOURCE FILE [Calc.java] 



name 


class, °/o 


method. % 


block, % 


line, °/o 


Calc. Java 


100% (1/1) 


100* (2/2) 


1005 (7/7) 


1UU% Vl/2) 



COVERAGE BREAKDOWN BY CLASS AND METHOD 



name 




class, % 


method, % 


block, °/b 


line, °/o 




class Calc 


100% (1/1) 


100% (2/2) 


100% (7/7) 


100% (2/2) 


Calc [) : void 




100% (1/1) 


100% (3/3) 


100% (1/1) 


divise (double, double) : 


double 




100% (1/1) 


100% (4/4) 


100% (1/1) 



1 

2 
3 

8 


package f r . cyrol les . cxcntplcs , j unit; 
public class Calc ( 

public double divise (double nom, double denom) { 
return nom / denom; 


) 
} 



Figure 5.11 

Analyse de couverture de la ciasse Calc 



Utilisation des tests unitaires pour le refactoring 

Comme nous l'avons vu au chapitre precedent, les tests unitaires sont necessaires pour 
valider qu'une operation de refactoring n'a pas cause de regression dans le logiciel. lis 
permettent aussi de detecter des erreurs propres aux nouveaux elements introduits par la 
refonte, comme une methode extraite insuffisamment securisee pour etre reutilisee en dehors 
du code existant. 

Les sections qui suivent presentent la demarche d' utilisation des tests unitaires et en 
donnent un exemple d' application. 



La demarche 



L'utilisation des tests unitaires suit toujours la meme logique, quelle que soit l'operation 
de refactoring effectuee. Une operation de refactoring ne devant pas modifier le compor- 
tement du logiciel, l'idee est d'encadrer le perimetre de la refonte par des tests unitaires 
qui seront valables avant et apres la refonte. 

Cette demarche suppose que les tests unitaires soient developpes avant l'operation de 
refactoring et valides sur le code existant. Les tests unitaires peuvent en effet contenir des 
erreurs, tout comme le code existant. II faut s'assurer par ailleurs qu'ils ont une couverture 
suffisante du code a refondre afin d' avoir le maximum de chances de detecter des regres- 
sions. Une fois la refonte effectuee, il suffit de les rejouer pour detecter d'eventuelles 
regressions introduites par la refonte. 

Pour les tests unitaires portant sur le code inclus dans le perimetre de la refonte, des 
adaptations sont generalement necessaires pour permettre leur fonctionnement apres 
l'operation de refactoring. Puisqu'ils sont generalement fortement modifies, ils ne peuvent 
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servir de base a des tests de non-regression mais sont neanmoins utiles pour detecter 
d'eventuelles erreurs issues de la refonte. De nouveaux tests unitaires peuvent etre deve- 
loppes afin de tester les nouveaux elements introduits par l'operation de refactoring, par 
exemple, une methode extraite. 

La figure 5.12 illustre cette demarche. 




Etapes 

1. 

Definition du perimetre des 
tests de non-regression 
2. 

Developpement et 
validation des tests 
unitaires de non- 
regression 
3. 

Developpement des tests 
unitaires classiques 

4. 

Lancement des tests 
unitaires classiques 



Lancement des tests de 
non-regression 



Figure 5.12 

Demarche de test pour une operation de refactoring 



Exemple d 'application 

Reprenons 1' exemple de mise en oeuvre de 1' extraction de methode du chapitre precedent. 
Celui-ci repose sur la classe PersonnePhysique, qui possede deux methodes tres proches 
d'un point de vue algorithmique, possedeGarcon et possedeFille. 

Definition du perimetre des tests de non-regression 

Pour rappel, ces deux methodes partagent le meme algorithme aux constantes pres 
(celles qui correspondent au sexe de l'enfant), ce qui justifie une extraction de methode 
afin de supprimer la duplication de code. 

La zone impactee par la refonte est cantonnee au corps des methodes possedeGarcon et 
possedeFille. L'operation de refactoring doit done etre totalement transparente pour les 
appelants de ces deux methodes. Ces appelants constituent le perimetre des tests de non- 
regression, car ce sont les entites les plus proches de la zone impactee par la refonte. 
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Definition des tests de non-regression 

Nous fonderons nos tests de non-regression sur differents appels aux methodes possede- 
Garcon et possedeFil le d'instances de la classe PersonnePhysique. 

Nous testerons les cas de figure suivants : 

• La personne a une fille et un garcon. 

• La personne a un garcon et pas de fille. 

• La personne a une fille et pas de garcon. 

• La personne n'a ni fille, ni garcon. 

Quatre instances differentes de la classe PersonnePhysique seront necessaires. 

Le cas de test de non-regression correspondant est le suivant : 

package f r.eyrol les.exemples. junit; 

import java.util .Date; 

import junit .framework. TestCase; 

import f r.eyrolles.exemples . PersonnePhysique; 

public class EnfantsTest extends TestCase { 

public EnfantsTest(String pNom) { 

super(pNom) ; 
} 

public void testUnefillellnGarcont ) ( 

PersonnePhysique fille = new PersonnePhysiqueC'Dupont" 

, "Jul iette" , ' F' ,new Date( ) ,nul 1 ) ; 
PersonnePhysique garcon = new PersonnePhysiqueC'Dupont" 

, "Marc" , 'M' , new DateO .null ); 
PersonnePhysique enfants[] = {fil le, garcon} ; 
PersonnePhysique personne = new PersonnePhysiqueC'Dupont" 

, "Emile" , 'M' ,new DateO ,enf ants) ; 
a ssertTrue( per sonne. possedeFil let )) ; 
as sertTruet per sonne. possedeGarcont ) ) ; 
} 

public void testUnefillePasGarcont ) { 

PersonnePhysique fille = new PersonnePhysiqueC'Dupont" 

, "Jul iette" , ' F' .new Date( ) ,nul 1 ) ; 
PersonnePhysique enfants[] = {fille}; 
PersonnePhysique personne = new PersonnePhysiqueC'Dupont" 

, "Emile" , 'M' , new Date( ) , enfant s) ; 
as sertTrue( per sonne. possedeFil let )) ; 
as sertFal set personne. possedeGarcont ) ) ; 
} 

public void testUnGarconPasFillet ) { 

PersonnePhysique garcon = new PersonnePhysiqueC'Dupont" 

, "Marc" , 'M' .new DateO .null ); 
PersonnePhysique enfants[] = {garcon}; 
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PersonnePhysique personne = new PersonnePhysiquet "Dupont" 

, "Emile" , 'M' ,new Date( ) .enfants) ; 
assertFal se( personne. possedeFil let ) ) ; 
assertTrue(personne.possedeGarcon( ) ) ; 
} 

public void testPasFillePasGarcon( ) { 

PersonnePhysique personne = new PersonnePhysiquet "Dupont" 

, "Emile" , 'M' .new Date( ) ,nul 1 ) ; 
assertFal se( personne. possedeFil let ) ) ; 
assertFal set personne. possedeGarcont ) ) ; 
} 
} 

Si nous executons ce cas de test sur le code existant (non refondu), nous constatons que 
la classe PersonnePhysique ne passe pas tous les tests avec succes. Le dernier, testPas- 
FillePasGarcon, echoue puisque le cas oil PersonnePhysique n'a pas d'enfant (attribut 
enfants egal a null) n'est pas gere. II est done necessaire de corriger le probleme avant 
d'effectuer la refonte. 

Une fois le probleme corrige, nous pouvons relancer le cas de test pour valider la correction. 
Cela demontre tout l'interet de tester le code existant avant le refactoring pour ne pas 
reconduire de bogues. 

Si nous realisons une analyse de couverture avec EMMA, nous constatons que les methodes 
testees (possedeFil le et possedeGarcon) sont couvertes a 100 %. 

Definition des tests unitaires propres au code refondu 

Pour completer les tests de non-regression, nous pouvons definir des tests specifiques 
pour la nouvelle methode rechercheGenre, extraite des methodes possedeFil le et possede- 
Garcon. 

Pour rappel, la methode rechercheGenre accepte un unique parametre de type caractere, 
correspondant a la lettre du genre recherche (M pour masculin et F pour feminin). 

Nous pouvons imaginer les tests suivants : 

• La personne possede un enfant de genre feminin. 

• La personne possede un enfant de genre masculin. 

• La personne possede un enfant d'un genre indefini, e'est-a-dire autre que F ou M. 
L'objectif est de tester le comportement de rechercheGenre en cas de passage d'un para- 
metre ayant une valeur aberrante (nous attendons que la methode renvoie f al se). 

Le cas de test JUnit correspondant est le suivant : 

package fr.eyrol les . exemples. junit; 

import java.util .Date; 

import junit.framework.TestCase; 

import f r.ey roll es. exemples. PersonnePhysique ; 

public class RechercheGenreTest extends TestCase ( 
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public RechercheGenreTesttString pNom) { 

super(pNom) ; 
} 

public void testFeminin () { 

PersonnePhysique fille = new PersonnePhysiqueC'Dupont" 
, "Jul iette" , ' F' ,new Datet ) ,nul 1 ) ; 
PersonnePhysique enfants[] = {fille}; 
PersonnePhysique personne = new PersonnePhysiqueC'Dupont" 
, "Emile" , 'M' ,new DateO .enfants) ; 
assertTrue(personne.rechercheGenre( ' F' ) ) ; 
} 

public void testMasculint ) { 

PersonnePhysique garcon = new PersonnePhysiqueC'Dupont" 

, "Marc" , 'M' , new Datet ) ,nul 1 ) ; 
PersonnePhysique enfants[] = {garcon}; 
PersonnePhysique personne = new PersonnePhysiqueC'Dupont" 

, "Emile", 'M' , new DateO .enfants) ; 
assertTrue(personne.rechercheGenre( 'M' ) ) ; 
} 

public void testlndetermine( ) { 
PersonnePhysique fille - new PersonnePhysiqueC'Dupont" 

, "Jul iette" , ' F' ,new Datet ) ,nul 1 ) ; 
PersonnePhysique enfants[] = {fille}; 
PersonnePhysique personne = new PersonnePhysiqueC'Dupont" 

, "Emile", 'M' , new Date( ) , enfant s) ; 
a ssertFal set personne. rechercheGenret 'W )); 



Pour les besoins du test, la methode rechercheGenre est rendue publique alors qu'a 
l'origine elle est privee, puisqu'elle n'est pas censee etre utilisee directement. Rappelons 
que nous ne pouvons tester avec le framework JUnit que les methodes publiques d'une 
classe. 

Realisation de la refonte et tests 

Une fois la refonte effectuee a l'aide de l'assistant d'extraction de methode d'Eclipse, 
nous pouvons executer notre cas de test specifique de la methode nouvellement creee 
(rechercheGenre) afin de valider son fonctionnement propre. Si nous lancons le cas de test 
RechercheGenreTest, nous constatons qu'il n'a pas genere d'erreur. 

Une fois le fonctionnement de rechercheGenre valide, nous pouvons realiser les tests de 
non-regression pour verifier que la refonte n'a pas genere de regression. Pour cela, nous 
lancons le cas de test EnfantsTest pour la deuxieme fois, la premiere ayant ete effectuee 
sur le code non refondu. Nous constatons, la encore, qu'il n'y a pas d'erreur. 

Grace a ces deux cas de test, nous pouvons raisonnablement considerer que l'operation 
de refactoring a ete realisee avec succes. 
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Conclusion 

La mise en oeuvre de tests unitaires est souvent percue par les chefs de projet comme une 
perte de temps. Or ceux-ci detectent les anomalies tres en amont dans le developpement, 
rendant leur correction beaucoup plus simple, car beaucoup plus proche du code, que la 
recette faite par les utilisateurs au travers de 1'IHM. 

La capitalisation de ces tests automatises permet de detecter rapidement des regressions 
tout au long du cycle de vie du logiciel, notamment pendant les phases de refactoring. 
II est done fondamental de capitaliser des la creation du logiciel pour anticiper l'avenir. 

Ce chapitre clot la partie consacree au processus de refactoring. A la partie II, vous 
decouvrirez ou approfondirez des techniques de refactoring avancees. Celles-ci ne bene- 
ficient pas du meme outillage que les techniques de base et impactent plus fortement la 
structure du logiciel. Leffort de test associe a leur application est done beaucoup plus 
important. De ce fait, les outils que nous venons de presenter vous seront tres utiles. 



Partie II 



Techniques avancees 
de refactoring 



La partie II a presents le processus de refactoring d'un logiciel et detaille les techniques 
de base d'une refonte logicielle. 

La presente partie decrit des techniques plus avancees, mais aussi plus difficiles a 
mettre en oeuvre, du fait de la quasi-absence de leur support par les environnements de 
developpement tels qu'Eclipse. 

Ces techniques avancees sont les suivantes : 

• Refactoring avec les design patterns. Les designs patterns sont des modeles de 
conception generiques eprouves, qui, appliques a un logiciel, lui assurent un respect 
des meilleures pratiques orientees objet. De ce fait, leur utilisation dans le cadre 
d'un projet de refactoring est pertinente pour ameliorer sa qualite. 

• Refactoring avec la programmation orientee aspect. La POA est un nouveau 
paradigme de programmation, complementaire de la programmation orientee objet, 
offrant une nouvelle dimension de modularisation grace a la notion d' aspect. Nous 
presentons quelques techniques reposant sur la POA permettant d' ameliorer la 
qualite d'un logiciel. 

• Refactoring de base de donnees. En regie generale, un logiciel ne se limite pas a 
du code. II repose sur des briques logicielles tierces, comme les bases de donnees. 
A ce titre, il est interessant d'etudier comment les techniques de refonte de bases de 
donnees relationnelles, que cela concerne leur structure ou leur mode d'acces, 
ameliorent la qualite generale du logiciel. 
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Le refactoring 
avec les design patterns 



Les design patterns, ou modeles de conception reutilisables, apportent des solutions generi- 
ques a des problemes recurrents rencontres dans le developpement de logiciels. Ces modeles 
sont independants des langages mais reposent pour la plupart sur l'approche orientee objet. 

Un certain nombre de design patterns ont ete popularises en 1995 par l'ouvrage collectif 
Design patterns : catalogue de modeles de conception reutilisables, de Erich Gamma, 
Richard Helm, Ralph Johnson et John Vlissides, plus connus sous le nom de Gang of 
Four, ou GoF. Si, depuis lors, de nombreux autres design patterns ont ete formalises, un 
grand nombre d'entre eux derivent des travaux du GoF. 

De par leur nature, les design patterns visent a introduire au sein des logiciels les meilleures 
pratiques de conception et peuvent etre employes dans les projets de refactoring pour 
ameliorer la qualite de l'existant. 

Nous commencons par donner une description synthetique de ces modeles de conception 
reutilisables puis presentons 1' utilisation de quelques design patterns du GoF particulie- 
rement utiles dans le cadre d'un projet de refactoring. 

Les design patterns 

Les design patterns, en francais modeles de conception, constituent une des materialisations 
de ce concept fort de la programmation orientee objet qu'est la reutilisation. 

Pour reprendre une image evoquee par Jim Coplien dans Software Patterns, les design 
patterns peuvent etre vus un peu comme des patrons de couturiere. La finalite d'un patron 
est de faire un habit, qui est le probleme a resoudre. Les caracteristiques de cet habit 
constituent le contexte, et les instructions du patron la solution. 
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Pour etre facilement utilisable, un design pattern doit etre correctement documente. Dans 
les differents catalogues de design patterns, celui du GoF etant le plus connu, chacun 
d'eux est generalement decrit au travers de plusieurs rubriques, notamment les suivantes : 

• nom du design pattern ; 

• description du probleme concerne par le design pattern ; 

• description de la solution (structure, collaborations) et de ses eventuelles variantes ; 

• resultat obtenu avec ce design pattern et eventuelles limitations ; 

• exemples ; 

• design patterns apparentes. 

Grace a cette documentation, la mise en oeuvre des design patterns est a la portee de tous 
et permet, a moindre cotlt, d'integrer les meilleures pratiques au sein des developpe- 
ments. II reste bien entendu necessaire de comprendre le fonctionnement et le domaine 
d'application d'un design pattern pour bien l'utiliser. 

Arm d'illustrer notre propos, prenons l'exemple d'un des design patterns les plus simples 
du GoF, le singleton : 

• Le probleme. Certaines classes ne doivent pas avoir plus d'une instance lors de 
1' execution du programme auquel elles appartiennent. Cela se justifie soit par la nature 
de la classe (elle modelise un objet unique, comme un ensemble de variables globales 
a 1' application), soit par souci d'economie de ressource memoire (une instance unique 
fournit le meme niveau de service que de multiples instances). 

• La solution du probleme. La classe doit comporter un attribut statique, generalement 
appele instance, destine a recevoir la reference de l'instance unique pour l'ensemble 
du logiciel, et une methode, generalement appelee getlnstance, renvoyant la valeur 
d'instance. Si instance est vide, getlnstance cree une nouvelle instance de la classe en 
la stockant dans l'attribut instance et la renvoie a l'appelant. 

Le code ci-dessous montre un exemple d' implementation d'un singleton en Java : 

public class MySingleton { 

private static MySingleton instance = null; 
protected MySingletont) { 

} 

public static MySingleton getlnstance( ) { 

if (instance==nul 1 ) { 

instance = new MySingletont); 

} 

return instance; 
} 

} 
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Grace a la methode getlnstance, les classes utilisatrices de la classe MySingleton sont 
certaines d'utiliser la meme instance de cette derniere. L' inconvenient est que l'operateur 
new n'est pas utilisable par les appelants. L' application du design pattern singleton a la 
classe MySingleton n'est done pas transparente pour les classes utilisatrices, puisqu'elles 
doivent appeler en lieu et place du constructeur la methode getlnstance. 

Ann d'eviter la creation d'instances de MySingleton par d'autres biais que la methode 
getlnstance, nous declarons son constructeur avec une portee protegee. Ainsi, seuls les 
descendants de MySi ngl eton sont en mesure d'utiliser directement ce constructeur. 

Mise en ceuvre des design patterns dans le cadre du refactoring 

La formalisation des design patterns utilisee habituellement est concue de maniere a faci- 
liter la phase de conception d'un logiciel. Elle ne prend pas en compte les contraintes liees a 
leur application sur du code existant. 

II est done necessaire de completer cette formalisation pour pouvoir etendre la portee des 
design patterns au refactoring, notamment pour les criteres suivants : 

• Gains attendus et risques a gerer. II est necessaire de contrebalancer les gains par les 
risques encourus. En fonction du contexte, il preferable de ne pas appliquer un design 
pattern si les gains attendus sont faibles en comparaison des risques pris. 

• Moyens de detection des cas d'application. La partie dediee a la description du 
probleme adresse par le design pattern et a son contexte est souvent insuffisante pour 
detecter les cas d' application dans du code existant. 

• Modalites d'application et tests associes. Dans le cadre d'un projet de refactoring, 
les modalites d'application d'un design pattern different de leur formalisation clas- 
sique puisqu'ils modifient du code existant. Les tests de non-regression doivent done 
etre integres a la demarche afin de garantir le succes de la refonte. 

Les design patterns du GoF sont regroupes selon les trois modeles suivants : 

• Modeles createurs. Design patterns specialises dans la creation d'objets. Les plus 
connus sont la fabrique et le singleton. 

• Modeles structuraux. Design patterns definissant differentes structures permettant la 
composition d'objets au-dela de la technique d'heritage. Les plus connus sont l'adap- 
tateur et la facade. 

• Modeles comportementaux. Design patterns proposant des structures de classes 
remarquables pour modeliser des comportements au sein des logiciels. Les plus connus 
sont la chaine de responsabilite et l'observateur. 

Dans les sections suivantes, nous nous concentrons sur les modeles comportementaux et 
structuraux du GoF, dont les benefices dans le cadre d'un refactoring sont les plus evidents. 

Les modeles createurs sont volontairement ecartes, car, hormis pour le singleton, les cas 
d'utilisation ne sont pas aussi clairs que dans les autres modeles. Le lecteur interesse pourra 
s'inspirer de notre demarche pour introduire ces design patterns dans ses projets de refonte. 
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Utilisation des modeles comportementaux 

Les modeles comportementaux sont particulierement interessants du fait que leur appli- 
cation est generalement bien circonscrite, ce qui diminue les effets de bord et facilite les 
tests de non-regression. 

Le pattern observateur 

Au cours de sa vie, un objet peut etre amene a changer plusieurs fois d'etat. Au niveau de 
1' application, ces changements d'etat generent des traitements. Par exemple, pour un trai- 
tement de texte, la modification du fichier ouvert doit activer la fonctionnalite d'enre- 
gistrement. 

Si la classe de notre objet a la charge d'effectuer tous les traitements lies a ces change- 
ments d'etat, nous pouvons arriver rapidement a une classe obese, difficile a maintenir. 

Le design pattern observateur permet a un objet de signaler un changement de son etat a 
d'autres objets, appeles observateurs. Ce design pattern est particulierement adapte a la 
programmation d'lHM graphiques. Tout controle graphique signale ses differents chan- 
gements d'etat au travers d'evenements captures par divers objets pour realiser leurs 
traitements propres. Par exemple, dans un logiciel de traitement de texte, le clic sur un 
bouton de la barre d'outils declenche des traitements qui sont pris en charge non pas 
directement par celui-ci, mais par ses observateurs. 

Le design pattern observateur est simple a implementer avec Java. L'API standard de 
J2SE fournit une interface (java.util .Observer) et une classe (Java. util .Observable) 
offrant la base necessaire. 

L'interface Observer doit etre implementee par les classes des observateurs. Cette interface 
ne comprend qu'une seule methode, update, qui est appelee pour notifier l'observateur d'un 
changement au niveau du sujet d'observation. 

La classe Observabl e doit etre utilisee par la classe observee. Cette classe fournit la meca- 
nique d'inscription et de desinscription des observateurs (methodes addObserver et dele- 
teObserver) ainsi que la mecanique de notification (methodes notifyObservers). 

L'utilisation d'Observable par la classe observee peut se faire de deux manieres. La 
premiere consiste a employer 1' heritage, avec toutes les contraintes que cela impose 
(impossibilite d'heriter d'autres classes). La seconde consiste a creer une classe interne 
heritant d'Observable. Cette derniere maniere nous semble plus adaptee a un contexte 
de refactoring. Elle offre de surcroit davantage de flexibilite dans le cas ou la classe 
observee comporte plusieurs sujets d'observation (il suffit de creer une classe interne 
par sujet). 

Le schema UML de la figure 6.1 illustre l'utilisation de ce design pattern dans le cadre 
d'une refonte. 
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Figure 6.1 

Refonte avec le design pattern observateur 



Gains attendus et risques a gerer 

Le gain attendu par l'utilisation du design pattern observateur est de simplifier les rela- 
tions unidirectionnelles (observe vers ses observateurs) qu'entretient une classe donnee 
avec les autres. Grace a ce design pattern, nous pouvons convertir des relations « en dur » 
(la classe connait explicitement tous ces observateurs, creant ainsi une dependance 
directe au niveau du code) par un processus generique et dynamique beaucoup plus 
souple a maintenir et a faire evoluer. 

Les risques a gerer sont proportionnels au nombre d' observateurs identifies pour une 
classe donnee puisque la mise en place de ce design pattern les impacte directement. II 
faut particulierement veiller a ce que les relations entre les observateurs et l'observe 
soient unidirectionnelles (observe vers observateurs). Le fonctionnement de la classe ne 
doit pas etre « perturbe » par le fait qu'elle est observee. 
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II faut toutefois veiller a ne pas abuser de ce design pattern, applicable potentiellement a 
un grand nombre de situations, et a le reserver a des cas oil sa genericite constitue un 
apport reel par rapport a l'existant. 

Moyens de detection des cas d'application 

Les classes ayant un couplage afferent important peuvent cacher des sujets d' observation. 
Cependant, la metrique du couplage est insuffisante pour detecter efficacement la plupart 
des cas d' utilisation dans lesquels une classe est observee par un faible nombre d'obser- 
vateurs. 

Seule une etude des interactions entre les classes permet de connaitre reellement les bons 
candidats. Afin de reduire le perimetre de recherche, il est preferable de se concentrer sur 
les classes importantes du logiciel, que ce soit par leur complexite ou leur criticite. 

Modalites d'application et tests associes 

La premiere etape consiste a determiner les sujets d'observation et les observateurs. 
Chaque sujet d'observation et ses changements d'etat doivent etre clairement identifia- 
bles afin d'extraire la logique correspondante et de la reinjecter dans la mecanique de 
notification. Pour chaque observateur, il faut s'assurer qu'il n'entretient pas d'autres rela- 
tions avec le sujet d'observation ne pouvant etre couvertes par le mecanisme de notification. 

Afin de minimiser les risques, nous conseillons de mettre en place ce design pattern de 
maniere progressive, c'est-a-dire un sujet d'observation a la fois, observateur par obser- 
vateur. 

Chaque sujet d'observation necessite d'avoir une classe interne heritant de la classe 
java.uti 1 .Observable. Cette classe interne doit surcharger les methodes notifyObservers 
pour pouvoir declencher la notification par la classe observee. En effet, cette derniere 
etant la mieux placee pour signaler un changement d'etat d'un sujet d'observation, c'est 
elle qui appelle les methodes notifiyObservers. 

Pour chacune des classes internes, un attribut de ce type dans la classe observee est cree. 
C'est lui qui est utilise pour declencher les notifications et gerer les abonnements des 
observateurs. Concernant ce dernier point, il est necessaire de le rendre accessible aux 
observateurs afin qu'ils puissent s'inscrire. Pour cela, une methode get doit etre creee 
specifiquement pour cet attribut. 

Une fois la mecanique d'inscription/desinscription et de notification en place dans la 
classe observee, il faut la tester. Pour cela, des tests unitaires avec des simulacres d'objets 
pour les observateurs doivent etre mis en place pour chaque sujet d'observation et chaque 
changement d'etat associe. 

Ensuite, chaque observateur doit etre modifie de maniere qu'il s'inscrive aupres du ou des 
sujets d'observation qui l'interessent (un meme observateur peut observer plusieurs classes 
et plusieurs sujets d'observation). Pour cela, il utilise la methode get precedemment creee 
pour le sujet d'observation qui l'interesse afin de pouvoir appeler la methode addObserver. 
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Pour terminer, chaque observateur doit implementer l'interface java.util .Observer en 
implementant sa methode publique update. Cette methode doit contenir la logique 
declenchant les traitements idoines lors d'un changement d'etat d'un sujet d'observation 
(la methode update est utilisee pour tous les sujets d'observation, la differentiation se 
faisant grace a son premier parametre, qui renvoie la reference a l'objet Observabl e ayant 
declenche la notification). 

Pour chaque observateur, il est important de tester le bon traitement des notifications. 
Nous pouvons ecrire des tests unitaires avec, si necessaire, un simulacre d'objet pour le 
sujet d'observation. Une fois l'observateur teste, les hens directs entre le sujet d'observation 
et ses observateurs peuvent etre supprimes au profit des mecanismes du design pattern 
observateur. 

II est alors necessaire de tester l'ensemble a partir du sujet d'observation afin de s'assurer 
qu'il n'y a pas eu de regression. Pour cela, nous pouvons utiliser des tests valides sur la 
version originelle de la classe observee. 

Exemple de mise en ceuvre 

Supposons que, dans le cadre d'un site Web marchand, une classe Pani er soit definie pour 
traiter le panier d'achat des clients. Cette classe comporte une methode declencheCom- 
mande, qui declenche les traitements associes a la validation de la commande par le client 
(verification des coordonnees, paiement, controle des stocks, etc.). Ces traitements obligent 
la classe Pani er a avoir un acces a differents objets du logiciel pour les prendre en charge, 
notamment les objets de gestion de stock et de comptabilite. 

Une implementation possible, partiellement reproduite ici, de la classe Panier pourrait se 
presenter de la maniere suivante : 

package f r.ey roll es.exemples. patterns. observateur; 

import java.util .Vector; 

public class Panier { 
//... 

private GestionDeStock stock; 
private Comptabilite compta; 
private Vector contenu; 

public void declencheCommandet ) { 

stock. traite( contenu) ; 
compt a. traite( contenu) ; 

} 
) 

Fondamentalement, la classe Panier n'a pas besoin d'avoir un lien direct avec la gestion 
de stock et la comptabilite. La validation d'une commande par le client doit etre vue 
comme un evenement declenchant plusieurs traitements independants, dont le detail n'a 
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pas besoin d'etre connu par la classe Pani er. L' utilisation du design pattern observateur a 
done tout son sens dans cette situation. 

Dans cet exemple, le sujet d'observation est le declenchement de la commande. Nous 
allons creer une classe interne derivant de java.util .Observable, l'instance correspon- 
dante au sein du sujet d'observation, et la methode get permettant d'acceder a l'attribut 
stockant cette instance : 

package fr.eyrol les.exemples. patterns. observateur; 
import Java .util .Vector; 
import java.util .Observable; 

public class Panier { 

private DeclenchementCommande sujet = 
new DeclenchementCommandet ) ; 

public DeclenchementCommande getSujetO { 

return sujet; 
} 

public class DeclenchementCommande extends Observable { 
public void notifyObserverst) { 
super. setChangedt ) ; 
super. notifyObserverst ) ; 
} 

public void notifyObservers(Object p) ( 
super. setChangedt ) ; 
super. notifyObservers(p) ; 

) 
} 
) 

Nous constatons dans 1' implementation de la classe interne que des appels a la methode 
setChanged sont effectues. lis sont necessaires pour indiquer qu'il y a eu changement 
d'etat du sujet d'observation. Sans ces appels, les appels aux methodes notifyObservers 
qui suivent sont sans effet, et les observateurs ne sont pas notifies. 

Pour terminer avec la classe Panier, il est necessaire de mettre en place la mecanique de 
declenchement des notifications. Pour cela, il suffit de modifier la methode declencheCom- 
mande pour qu'elle appelle la methode notifyObservers de l'attribut sujet : 

public void declencheCommande( ) { 
sujet.notifyObservers(contenu) ; 

stock. traite(contenu) ; 
compta.traite(contenu) ; 

} 
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Apres avoir teste le bon fonctionnement de cette nouvelle mecanique, nous pouvons 
modifier les classes GestionDeStock et Comptabilite. Pour GestionDeStock, nous devons 
implementer l'interface Observer (la logique est similaire pour Comptabi 1 i te) : 

package f r.ey roll es.exemples. patterns. observateur; 

import Java. util .Observable; 
import Java. util .Observer; 
import Java. util .Vector; 

public class GestionDeStock implements Observer { 
public void traite(Vector p) ( 



public void update(Observable pSujet, Object pArg) ( 
if (pSujet instanceof Panier.DeclenchementCommande) 
traitet ( Vector )pArg) ; 



Ici, la methode update est prevue pour traiter differents sujets d' observation. La differen- 
tiation des sujets s'effectue en testant la classe du sujet. 

Maintenant que l'interface Observer est implementee par ces deux classes, nous pouvons 
tester la notification en appelant directement la methode update. 

Pour achever la mise en place du design pattern observateur, il est necessaire de mettre en 
place la mecanique d'inscription des observateurs. Dans cet exemple, cette mecanique 
peut etre mise en place, par exemple, par la classe chargee de la creation des paniers. 

Une fois cette operation terminee, nous pouvons supprimer les liens directs entre Panier 
et ses observateurs. La methode declencheCommande est alors expurgee des appels aux 
methodes de GestionDeStock et de Comptabilite : 

public void declencheCommandet ) ( 
sujet.notifyObservers(contenu) ; 

// SUPPRIME : stock. traite(contenu); 
// SUPPRIME : compta.traite(contenu); 



Grace au design pattern observateur, la classe Panier devient plus facilement reutilisable, 
puisque les liens directs avec la comptabilite et la gestion de stock ont disparu, et offre 
plus de flexibilite grace a son mecanisme d' observation generique. 
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Le pattern etat 

Le comportement des methodes d'une classe peut varier en fonction de l'etat interne de 
l'objet. Si les variations sont importantes et clairement associees aux changements d'etat, 
la complexite introduite par la gestion de ces differences en fonction de l'etat peut rendre 
la classe difficile a maintenir. 

L'idee sous-jacente du design pattern etat est simple : il faut proceder par dichotomie, 
c'est-a-dire dissocier la gestion de l'etat de l'objet de son comportement. Concretement, 
cela consiste a creer une classe par etat possible et de lui faire implementer le comporte- 
ment associe. 

Chaque classe d'etat derive d'une meme classe mere abstraite ou d'une interface speci- 
fiant les methodes a implementer. Pour la classe originelle, il suffit d'instancier la classe 
correspondant a son etat et d'utiliser ses services au travers de ses methodes publiques. 
Les services sont normalises d'un etat a l'autre grace a la classe mere abstraite ou a 
l'interface. La classe originelle n'a des lors pas a se preoccuper de l'etat dans laquelle 
elle se trouve. 

Le schema UML de la figure 6.2 illustre l'utilisation de ce design pattern dans le cadre 
d'une refonte. 

Gains attendus et risques a gerer 

Le gain attendu est la reduction de la complexite de la classe originelle et la clarification 
de sa structure en faisant apparaitre explicitement les differents etats dans lesquels un 
objet de ce type peut se trouver. La separation claire des differents etats facilite grande- 
ment la maintenance, et les effets de bord en cas de modification sont diminues. 

La refonte d'une classe existante avec ce design pattern est cependant une tache delicate, 
car elle s'effectue en profondeur. Les risques de regression sont d'autant plus importants 
que la gestion des etats est souvent profondement enfouie dans le code de la classe exis- 
tante. 

Moyens de detection des cas d'application 

La complexite cyclomatique peut nous aider a detecter des cas d'application de ce design 
pattern. Quand la gestion des etats est enfouie dans les methodes d'une classe, cela intro- 
duit souvent un grand nombre de tests pour savoir dans quel etat se trouve la classe. 

La gestion d'etats est loin d'etre la seule cause possible d'une complexite cyclomatique 
importante. Une analyse de la classe est necessaire pour identifier l'applicabilite du 
design pattern etat. Pour que celui-ci soit efficace, il est important de s'assurer que les 
etats sont clairement definis (par exemple, marche/arret) et en nombre limite, que les 
comportements associes different fortement d'un etat a l'autre et que la delegation de 
comportement a une classe d'etat n'engendre pas d' interactions complexes entre cette 
derniere et la classe originelle. 
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Figure 6.2 

Refonte avec le design pattern etat 



Modalites d'application et tests associes 

La premiere etape pour mettre en place ce design pattern est d' identifier les etats de 
I'objet et le comportement des methodes de la classe correspondante. Les etats doivent 
etre clairement identifiables et non ambigus (I'objet n'a qu'un seul etat a l'instant /). II en 
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va de meme pour les comportements correspondants. La mecanique de transition d'un 
etat a l'autre doit etre precisement definie. 

Avant d'effectuer la refonte, il est necessaire de developper un jeu complet de tests a valider 
sur le code existant, s'il n'existe pas. Ce design pattern doit etre totalement transparent 
vis-a-vis de l'exterieur. La reutilisation de ce jeu de tests est particulierement efficace 
pour detecter des regressions dans la classe refondue. II importe done de veiller a tester 
chaque etat identifie ainsi que toutes les transitions possibles d'un etat a l'autre. 

Pour materialiser les differents etats, nous utilisons des classes internes privees afin de 
masquer au reste du logiciel les details d'implementation. Cette facon de proceder faci- 
lite aussi la communication entre les etats et la classe originelle, ces derniers ayant acces 
aux elements prives et proteges de celle-ci (methodes, attributs). 

Chaque etat derive d'une classe abstraite ou implemente une interface reprenant 1' ensem- 
ble des methodes de la classe originelle dont le fonctionnement depend de l'etat. Ces 
methodes sont bien entendu abstraites. Les methodes de la classe originelle dont le 
comportement est invariant en fonction de l'etat ne sont pas prises en compte. 

Le choix entre une classe abstraite ou une interface depend du contexte du logiciel. Nous 
preferons utiliser une interface, qui est moins lourde qu'une classe abstraite. La classe 
abstraite peut cependant s'averer utile pour eviter la duplication de code entre les diffe- 
rents etats. 

Un attribut du type de la classe abstraite ou de l'interface doit etre ajoute a la classe origi- 
nelle. II represente l'etat courant et sera modifie par la mecanique de transition d'etat. 

Le contenu de chaque etat est obtenu en procedant a des extractions de code au sein de la 
classe originelle. Pour cela, nous pouvons nous aider des techniques de base du refactoring 
proposees par l'environnement de developpement. 

Le corps des methodes de la classe originelle dont le comportement depend de l'etat 
courant doit etre remplace par des appels aux methodes correspondantes de 1' attribut 
representant l'etat courant. 

Enfin, la mecanique de changement d'etat doit etre mise en place. Cette mecanique 
dependant tres fortement du contexte, il n'y a pas de regie d'or pour son implementation. 

La refonte achevee, nous pouvons utiliser le jeu de tests mis au point sur la classe originelle 
pour valider la classe refondue. 

Exemple de mise en ceuvre 

Supposons que nous ayons developpe un logiciel nomade pouvant fonctionner en mode 
connecte a un reseau ou en mode deconnecte, sur un ordinateur portable d'un representant 
de commerce, par exemple. Dans le cas du mode deconnecte, seul un sous-ensemble des 
fonctionnalites est disponible puisque seules les ressources de 1' ordinateur sont disponibles, 
en l'occurrence une base de donnees installee sur le poste nomade. 

Au niveau des classes du logiciel, cela se traduit par un comportement different en fonction 
de la presence ou non d'une connexion au reseau. 
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Pour la classe representant un contrat, nous avons le code suivant : 

package f r.ey roll es.exemples. patterns. eta t; 

import Java. sql .Connection; 
import Java. sql .PreparedStatement; 
import Java. sql .ResultSet; 
import java.util .Date; 

publ ic cl ass Contrat { 

private Connexionlnternet connexionlnternet; 
private int numero; 
private Date dateSignature; 
//... 

public Contrat chercheContrattint pNumero) 
throws ContratlnexistantException, ContratNonPresentException 

if (connexionlnternet. estDisponible( ) ) { 

connexionBDD - BDD.getConnexion(BDD.DISTANTE) ; 

} else { 

connexionBDD = BDD.getConnexion(BDD. LOCALE) ; 

} 

requete = connexionBDD. createStatement( ) ; 
resultat = requete. executeQuery( 

"select * from contrats where numero="+pNumero) ; 

if (Iresultat.nextO) { 

if (connexionlnternet. estDisponible( ) ) { 

throw new ContratlnexistantException(pNumero) ; 
} else { 

throw new ContratNonPresentException(pNumero) ; 



} 

public void enregistreContrat( ) { 

if (connexionlnternet. estDisponible( ) ) { 

connexionBDD = BDD.getConnexion(BDD.DISTANTE) ; 

} else { 

connexionBDD = BDD.getConnexion(BDD. LOCALE) ; 

} 



public Date getDateSignaturet ) ( 

return dateSignature; 
} 

public void setDateSignature(Date pDateSignature) 
dateSignature = pDateSignature; 
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public int getNumeroO { 

return numero; 
} 

public void setNumerotint pNumero) { 

numero = pNumero; 
) 
} 

Nous pouvons constater dans cet extrait que les methodes rechercheContrat et enregis- 
treContrat dependent de l'etat connecte ou non de la classe Contrat. Si nous sommes 
connects, une connexion a la base de donnees distante est creee, sinon c'est une 
connexion a la base de donnees locale qui est creee. La base de donnees locale ne conte- 
nant qu'un sous-ensemble des contrats, un echec de la recherche ne signifie pas necessai- 
rement son inexistence (le contrat peut exister dans la base de donnees distante contenant 
l'exhaustivite des contrats). L' exception generee en cas d'echec de la recherche change 
en fonction de l'etat. 

Les getters (getDateSignature, getNumero) et les setters (setDateSignature, setNumero) ne 
varient pas en fonction de l'etat. La transition d'un etat a l'autre depend de la valeur 
booleenne renvoyee par la methode estDisponible de l'objet connexion Internet. 

Les conditions pour implementer le design pattern etat sont done remplies : la classe 
possede deux etats distincts generant un comportement specifique. 

Nous allons l'appliquer et commencer en creant une interface reprenant les deux metho- 
des dependant de l'etat ainsi que l'attribut representant l'etat courant. Cette interface 
interne a la classe Contrat et l'attribut se presentent de la maniere suivante : 

public class Contrat { 

private Etat etatCourant; 

private interface Etat { 
public Contrat chercheContratd'nt pNumero) 
throws Contrat I nexi st ant Except ion, Contrat Non Present Except ion; 
public void enregistreContrat( ) ; 
} 
} 

Nous creons ensuite deux classes internes implementant cette interface (une par etat, 
connecte et non connecte) : 

public class Contrat { 

private class EtatConnecte implements Etat { 
public Contrat chercheContratd'nt pNumero) 
throws Con t ra 1 1 nexi stant Except ion, Contrat Non Present Except ion { 

connexion = BDD.getConnexion(BDD. DISTANTE) ; 
requete = connexion. createStatement( ) ; 
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resultat = requete.executeQuery( 

"select * from contrats where numero="+pNumero) ; 

if (Iresultat.nextO) { 

throw new ContratlnexistantException(pNuntero) ; 
} 

} 

public void enregistreContrat( ) { 

connexion = BDD.getConnexion(BDD.DISTANTE) ; 

} 
( 

private class EtatDeconnecte implements Etat ( 
public Contrat chercheContratO'nt pNumero) 
throws Cont rat I nexi stan t Except i on, ContratNon Present Except ion { 

connexion = BDD.getConnexion(BDD. LOCALE) ; 

requete - connexion. createStatement( ) ; 
resultat = requete. executeQueryt 

"select * from contrats where numero="+pNumero) ; 

if (Iresultat.nextO) { 

throw new ContratlnexistantException(pNumero) ; 
} 

} 

public void enregistreContrat( ) { 

connexion = BDD.getConnexiontBDD. LOCALE) ; 

) 



Nous constatons que la separation des comportements entre les etats connecte et deconnecte 
a introduit une duplication de code (la requete dans chercheContrat). Cette duplication 
peut etre evitee en factorisant le comportement commun au sein d'une classe abstraite 
Etat en lieu et place de l'interface. 

La mecanique de changement d'etat peut etre factorisee au sein d'une methode privee 
appelee changeEtat. Cette mecanique doit etre appelee avant chaque appel aux methodes 
des etats. Par ailleurs, le corps des methodes de la classe originelle doit etre remplace par 
des appels aux methodes correspondantes de l'etat courant (materialise par l'attribut 

etatCourant) : 

public class Contrat { 
Etat etatCourant; 
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private void changeEtatO { 

if ( connexion I nternet.estDisponiblet ) ) 

etatCourant - new EtatConnecte( ) ; 
} else { 

etatCourant = new EtatDeconnecte( ) ; 



public Contrat chercheContrat(int pNumero) 
throws ContratlnexistantException, ContratNonPresentException { 
changeEtat( ) ; 

etatCourant.chercheContrat(pNumero) ; 
} 

public void enregistreContrat( ) { 

changeEtat( ) ; 

etatCourant. en regis treContrat( ) ; 
} 

} 

Une autre facon d'implementer cette mecanique consisterait a utiliser le design pattern 
observateur afin que la classe Contrat soit notifiee de la disponibilite ou de l'indisponibilite 
de la connexion Internet. De chaque notification resulterait un changement d'etat. 

Comme nous pouvons le constater, la vision que la classe Contrat presente a l'exterieur 
reste inchangee. Nous pouvons done nous reposer sur un jeu de tests construit sur la version 
originelle pour detecter des regressions. 

Grace a 1' application du design pattern etat, les comportements connectes et deconnectes 
sont bien distingues, facilitant leur maintenance et leur evolution. 



Le pattern interpreteur 

Certains traitements recurrents necessaires a un logiciel s'averent soit difficiles ou fasti- 
dieux a programmer dans le langage Java du fait de sa generalite, soit necessitant un 
parametrage complexe pour prendre en compte tous les contextes utilisateur possibles. 

Face a ces problemes, l'utilisation d'un langage plus specialise que Java peut nettement 
simplifier le logiciel. Un exemple classique est le traitement des chaines de caracteres. La 
classe java. lang. String est tres pauvre pour la manipulation de chaines de caracteres, 
abstraction faite de certaines methodes apparues avec l'API de J2SE 1.4 (voir ci-apres 
V exemple de mise en ceuvre). Or, dans un logiciel de gestion, par exemple, le controle de 
la validite des donnees textuelles saisies est important. La realisation de controles 
complexes peut s'averer extremement couteuse en developpement et en test. II est done 
preferable d'utiliser un langage specialise, comme les expressions regulieres. 

La ou, en Java, un programme de quinze lignes est necessaire, l'utilisation des expres- 
sions regulieres permet de le ramener a quelques lignes, reduisant d'autant la complexite 
du logiciel. Java etant un langage universel, il est possible de trouver des interpreteurs 
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d'expressions regulieres ecrits en Java directement utilisables dans le code d'un logiciel. 
J2SE en a introduit un dans l'API java . uti 1 . regex a partir de la version 1.4. 

Concernant les traitements ayant un parametrage complexe pour prendre en compte tous 
les contextes utilisateur possibles, il peut etre preferable de les rendre entierement repro- 
grammables a l'aide d'un langage plus simple que Java. C'est typiquement l'idee des 
langages de script des progiciels de gestion (ERP), ces derniers ne pouvant integrer 
toutes les speciricites possibles d'une entreprise a une autre. La encore, Java beneticie 
d' interpreters pour des langages de script, a l'image de Jython (http://www.jython.org) ou de 
Groovy (http://groovy.codehaus.org), qui peuvent interagir avec des traitements Java. 

Gains attendus et risques a gerer 

En utilisant des langages interpretes plus specialises que Java, nous cherchons a reduire 
la complexite du code en nous reposant sur les apports fonctionnels apportes par le 
nouveau langage. Bien entendu, il est necessaire que l'interpreteur soit parfaitement integre 
a l'environnement Java pour que 1' operation ait un interet. 

Par la combinaison de Java et des langages de script, dont les traitements sont modifiables 
sans recompilation, nous cherchons a introduire plus de flexibilite dans le logiciel et a 
reduire la complexite introduite par la gestion de specificites d'utilisateurs ou d'un para- 
metrage complexe influencant fortement les traitements. 

La mise en place d'un interpreter n'est cependant pas une tache facile, car elle introduit 
les risques specifiques suivants, en plus de la regression : 

• Bogues de l'interpreteur. Comme tout composant logiciel, l'interpreteur possede ses 
propres bogues. Le debogage de ce type de composant peut necessiter des compe- 
tences en theorie des langages, voire s'averer impossible si l'acces aux sources n'est 
pas possible. 

• Bogues dans les programmes ecrits dans le nouveau langage. Le support d'outils de 
debogage pour ce type de langage est generalement inexistant, ce qui complexifie la 
correction. 

• Performances. L interpretation est une operation couteuse. II faut done veiller a ne pas 
l'utiliser dans des traitements necessitant des performances optimales. 

Ann de limiter les risques, il est preferable d'eviter les utilisations trop generalisees de ce 
design pattern et de concentrer son emploi sur les zones beneficiant tres fortement de ses 
apports. 

Moyens de detection des cas d'application 

Dans le cas des langages specialises, le mieux est de se demander quel serait leur apport 
dans le logiciel (approche top-down) par rapport a ses fonctionnalites. Typiquement, 
pour un logiciel de gestion devant effectuer de nombreux controles des donnees saisies, 
l'apport des expressions regulieres est appreciable. 



Techniques avancees de refactoring 

Partie II 

Dans le cas des langages de script, le mieux est d'etudier le parametrage du logiciel. Si 
celui-ci est complexe et influe fortement sur certains traitements, il peut etre interessant 
de transformer ces derniers en scripts. Par ailleurs, si le logiciel dispose de tres nombreuses 
variantes, dont les differences sont concentrees sur quelques traitements, il peut etre inte- 
ressant de les fusionner en une version unique, ne variant qu'au travers du contenu des 
scripts qui l'accompagnent. 

Modalites d'application et tests associes 

La premiere etape consiste a cartographier les traitements pouvant beneficier des services 
de l'interpreteur. Cette cartographie sert de base pour evaluer les gains et les risques a 
mettre en place ce design pattern. II s'avere particulierement efficace si les traitements 
concernes subissent de nombreuses operations de maintenance. 

Comme il s'agit de transformer des traitements existants dans un nouveau langage, nous 
sommes face a une reecriture. L' effort de test pour detecter les regressions est done 
important. Un jeu de tests le plus complet possible doit etre mis en place sur le code 
originel avant de proceder a la refonte. L' effort de test doit etre d'autant plus important 
que l'utilisation d'un nouveau langage, mal maitrise par les developpeurs, introduit des 
risques supplementaires. 

La migration des traitements existants vers le nouveau langage se fait souvent manuelle- 
ment. Si les traitements sont nombreux, il peut etre interessant d'evaluer des solutions de 
transformation automatique. Leur cout d'automatisation peut etre compense par des gains 
de productivite sur de gros volumes de code. 

Une fois la migration effectuee, les tests mis en place sur la version originelle peuvent 
etre reutilises. Nous considerons que 1' introduction du design pattern interpreteur ne 
modifie que 1' implementation des classes concernees. 

Exemple de mise en ceuvre 

Dans les applications Web, la gestion des formulaires constitue une part importante des 
traitements lies a l'interface homme-machine (IHM). Dans cette gestion, le controle des 
valeurs saisies dans les champs des formulaires est souvent important et necessaire, surtout 
du point de vue de la securite, pour eviter l'injection SQL, par exemple. 

En utilisant les fonctions du langage Java, ce controle est particulierement fastidieux et se 
materialise souvent par une succession de conditions assez longues et sans grande valeur 
ajoutee. 
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Par exemple, le code suivant teste qu'un champ date est au format attendu par le logiciel 
(jj/mm/aaaa). II s'agit d'une gestion elementaire, qui ne tient pas compte de toutes les 
subtilites liees aux dates, comme les annees bissextiles : 

public boolean verifieDate(String pDate) { 
int jour; 
int mois; 
int annee; 

if (!(pDate.length()==10)) { 

return false; 
} 
try { 

jour = Integer. parseInt(pDate.substring(0, 2) ) ; 

mois = Integer. parseInt(pDate.substring(3, 5) ) ; 

annee - Integer. parseInt(pDate. substring(6) ) ; 
} 
catch (NumberFormatException e) { 

return false; 
} 

if ((!pDate.substring(2,3).equals("/"))| | 
( IpDate. substring (5, 6) .equal s( "/")) ) { 

return false; 
} 
if ((jour>31)||(jour<D) { 

return false; 
} 
if ((mois>12)| |(mois<D) { 

return false; 
} 

return true; 
} 

Le format jj/mm/aaaa peut etre specifie sous forme d'expression reguliere de la maniere 
suivante : [0-3][0-9]/[0-l][0-9]/[0-9]{4}+. 

Les valeurs entre crochets representent l'intervalle numerique autorise pour un caractere. 
[0-3] indique que le caractere doit etre compris entre et 3. Comme cette sous-expres- 
sion est au debut de l'expression reguliere, elle s'applique au premier caractere, la sous- 
expression suivante ([0-9]) au second, etc. La sous-expression {4}+ signifie que la sous- 
expression qui la precede, en 1' occurrence [0-9], est valable pour exactement quatre 
caracteres consecutifs. 

Pour connaitre toutes les possibilites des expressions regulieres, reportez-vous a la javadoc 
de la classe java.util . regex. Pattern. 
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Le code devient le suivant : 

public boolean verifieDate(String pDate) { 
int jour; 
int mois; 
int annee; 

if (pDate.matches("[0-3][0-9]/[0-l][0-9]/[0-9]{4)+")) { 

return false; 
} 

jour - Integer. parseInt(pDate.substring(0, 2) ) ; 
mois = Integer. parseInt(pDate.substring(3, 5) ) ; 
annee = Integer. parselnttpDate. substring(6) ) ; 
if ((jour>31)| |(jour<D) { 

return false; 
} 
if ((mois>12)| |(mois<D) { 

return false; 
} 

return true; 
} 

Grace a l'utilisation des expressions regulieres, le code est reduit de neuf lignes (19 
contre 28 auparavant, soit une reduction d'un tiers). Par contre, les performances sont 
inferieures, la version avec interpreteur etant quatre fois plus lente que la version origi- 
nelle d'apres nos mesures. II faut done veiller a n'utiliser ce design pattern que dans des 
cas ou la performance n'est pas une priorite majeure, e'est-a-dire quand le coiit de la 
sous-performance est superieur aux gains en maintenance. 



Le pattern strategie 

Au sein d'une classe, le traitement effectue par une ou plusieurs methodes donnees peut 
fortement varier en fonction du contexte. Cela a pour consequence d'obscurcir le contenu 
de la methode en melant traitement et tests pour identifier le contexte dans lequel l'objet 
se situe. 

A partir du moment oil les variantes du traitement sont bien distinctes et en nombre 
limite, nous pouvons isoler chacune d'elles dans une classe specifique, appelee une stra- 
tegic. Ces strategies derivent toutes d'une classe abstraite ou d'une interface specifiant 
les methodes publiques offertes par chacune des strategies concretes. Au niveau de la ou 
des methodes dont sont extraites les strategies, seul subsiste le traitement permettant de 
selectionner la strategie adaptee au contexte. 

Le schema UML de la figure 6.3 illustre l'utilisation de ce design pattern dans le cadre 
d'une refonte. 
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Le code de la methode est simplifie : L\ 
elle selectionne la strategie correspondent 
au contexte et lui delegue les traitements 
qui en dependent. 



Strategie 



■trt1() 
■trt2() 



Les traitements d'une methode dependent Li, 
fortement du contexte, obligeant a inclure des 
conditions dans le code et rendant la logique 
propre a chaque contexte moins lisible. 
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Figure 6.3 

Refonte avec le design pattern strategie 



Chaque strategie est bien identifiee et peut evoluer 
de maniere plus independante. 



T\ 



Gains attendus et risques a gerer 

En dissociant traitements et gestion du contexte, nous ameliorons la maintenance du 
code. La comprehension de strategies specialisees sur un contexte specifique est genera- 
lement plus simple que celle d'un traitement adressant toutes les situations possibles. Par 
ailleurs, le design pattern strategie ameliore l'evolutivite du logiciel en facilitant l'intro- 
duction de nouvelles strategies, soit en ajout, soit en remplacement des anciennes. 

La complexite d' application de ce design pattern dans le cadre d'une refonte depend du 
nombre de strategies a extraire et de la complexite de leurs interactions avec le contexte. 
II s'agit d'une operation delicate, sauf si 1' association du contexte et de la strategie 
correspondante est simple, sans ambigui'te et portant sur des traitements peu complexes. 
Cependant, comme il s'agit d'une operation interne a une classe, son contrat vis-a-vis de 
l'exterieur reste inchange, et les tests de non-regression en sont d'autant facilites. 
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Lors de l'extraction des strategies, il faut prendre garde a la duplication de code entre les 
differentes strategies. Le code commun peut etre factorise au niveau de la classe abstraite 
dont derivent les strategies. Dans ce cas de figure, une interface ne peut pas etre utilisee. 

Moyens de detection des cas d'application 

La encore, la complexite cyclomatique peut identifier de bons candidats pour l'utilisation 
de ce design pattern. Cependant, du fait de la trop grande generalite de cette metrique, il 
est necessaire d'analyser la methode pour s'assurer de la pertinence de ce design pattern. 

II est notamment necessaire de verifier que le contenu de la methode s'articule autour 
d'une succession de conditions declenchant des traitements. Si les conditions portent de 
maniere reguliere sur les memes elements, il est probable qu'ils constituent un contexte. 
Si la part des traitements externes a l'une de ces conditions est faible, le design pattern 
strategie a de fortes chances d'etre applicable. 

Modalites d'application et tests associes 

La premiere etape consiste a identifier les differents contextes influencant le contenu des 
traitements a effectuer. Les contextes doivent etre en nombre fini et independants les uns 
des autres. Pour chaque contexte possible, les traitements associes doivent etre clairement 
identifies. 

Avant d'effectuer la refonte, il est necessaire de mettre au point un jeu de tests pour 
detecter d'eventuelles regressions. L'application de ce design pattern n'influencant que 
1' implementation de la classe originelle, le jeu peut etre utilise tel quel sur le code 
refondu. 

Une interface ou une classe abstraite, representant la notion de strategie, doit etre creee afin 
de definir les methodes a implementer pour chaque strategie (nous l'appelons Strategie). 
Elle doit etre dans la mesure du possible interne a la classe originelle, car il s'agit d'un 
detail d'implementation. Si des traitements sont communs entre differentes strategies, ils 
peuvent etre places dans la classe abstraite, excluant de fait l'utilisation d'une interface 
pour materialiser la notion de strategie. 

Dans la methode originelle, ou la classe originelle si la strategie est commune a plusieurs 
methodes, il est necessaire de creer une variable de type Strategie contenant la reference 
a la strategie a employer (nous 1' appelons strategi eCourante). Cette variable est initialisee a 
1' execution de la methode par un test pour determiner le contexte dans lequel cette 
derniere s'execute et la strategie correspondante. 

De ce fait, une classe implementant la notion de strategie est creee pour chaque contexte 
possible. Ces classes peuvent etre construites en combinant l'extraction de methodes dans 
la methode originelle et le deplacement d'elements (les methodes extraites). Les blocs de 
code extraits sont remplaces par des appels aux methodes de la variable strategi eCourante. 

Une fois la refonte effectuee, nous pouvons utiliser le jeu de tests construit precedemment 
pour detecter les regressions introduites par 1' operation de refactoring. 
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Exemple de mise en ceuvre 

Supposons que nous devions effectuer une refonte d'un logiciel de gestion de Aches 
de paie. Au sein de ce logiciel, il existe un moteur de calcul des charges patronales et 
salariales. 

Ces calculs, tres nombreux mais peu complexes, sont fortement influences par le statut de 
cadre ou non du salarie et par le fait que son salaire depasse ou non le plafond de la Secu- 
rite sociale. Nous avons done une logique commune aux differents contextes, mais des 
traitements specifiques pour chacun d'eux : 

public class CalculateurCharges { 

public void calculeCharges (Salarie pSalarie) { 
boolean cadre = pSal arie.isCadre( ) ; 
boolean depassePlafond = false; 
if (pSalarie.getSalaireBrut()>SECU.MONTANT_PLAFOND) { 

depassePlafond = true ; 
} 

//Calcul de la cotisation vieillesse plafonnee 
if (cadre) { 

if (depassePlafond) { 

//... 
} else { 
//... 

} 
} else { 

if (depassePlafond) { 

//... 
} else { 

//... 



//Calcul de la cotisation maladie 
if (cadre) { 

//... 
} else { 

//... 
} 
//Etc. 



Comme nous pouvons le constater, les differents contextes sont bien delimites et au nombre 
de quatre : 

• cadre sans depassement du plafond de la Securite sociale ; 

• cadre avec depassement du plafond ; 

• non-cadre sans depassement du plafond ; 

• non-cadre avec depassement du plafond. 
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Nous creons done une interface interne a la classe originelle reprenant les differents 
calculs dependant du contexte (nous ne reprenons que ceux donnes dans l'extrait, e'est- 
a-dire la cotisation vieillesse plafonnee et la cotisation maladie) : 

public class Cal culateurCharges { 

private interface Strategie { 

public void calculeVieil lessePl afonnee(Salarie) ; 
public void calculeMaladie(Salarie); 



Nous creons ensuite les quatre classes internes implementant cette interface (une par 
contexte possible) : 

public class CalculateurCharges { 

private class CadreSousPlafond implements Strategie { 

public void cal culeVieil lessePl afonneetSalarie pSalarie) { 



public void calculeMal a d i e ( S a 1 arie pSalarie) 



private class CadreDepPlafond implements Strategie { 

public void calculeVieillessePlafonneetSalarie pSalarie) 

} 

public void calculeMaladietSalarie pSalarie) { 



private class NonCadreSousPlafond implements Strategie { 
public void calculeVieil lessePl afonneetSalarie pSalarie) 



public void calculeMaladietSalarie pSalarie) 



private class NonCadreDepPl afond implements Strategie { 

public void calculeVieil lessePl afonneetSalarie pSalarie) 
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public void calculeMaladie(Salarie pSalarie) 



} 



Pour terminer, nous modiflons la methode originelle afin qu'elle selectionne la bonne 
strategie en fonction du contexte et qu'elle utilise ses services : 

public void calculeCharges (Salarie pSalarie) { 
Strategie strategieCourante ; 

if (pSal arie.isCadre( ) ) { 

if (pSalarie. getSal ai reBrut( )>SECU.MONTANT_PLAFOND) { 

strategieCourante = new CadreDepPlafondt ) ; 
} else { 

strategieCourante = new CadreSousPlafond( ) ; 
} 
} else { 

if (pSalarie. getSal aireBrut( )>SECU.MONTANT_PLAFOND) { 

strategieCourante = new NonCadreDepPlafondt ) ; 
} else { 

strategieCourante = new NonCadreSousPlafond( ) ; 
} 
} 

//Calcul de la cotisation vieillesse plafonnee 
strategieCourante.calculeVieillessePlafonnee( pSalarie) ; 

//Calcul de la cotisation maladie 
strategieCourante.calculeMal adie( pSalarie) 

//Etc. 



Grace a 1' application du design pattern strategie, le calcul des charges tel que presente dans la 
methode cal cul eCharges est deleste des tests rendant son code difficile a lire. Chaque strategie 
est clairement isolee des autres et se concentre sur les details de sa problematique. Ainsi, les 
risques de confusion au cours des operations de maintenance, comme un taux applique aux 
cadres alors qu'il s'agit de non-cadres, sont fortement reduits. 



Amelioration de la structure des classes 

Les modeles structuraux aident a simplifier la structure du logiciel en introduisant des 
modeles de composition d'objets plus clairs et efficaces. S'ils peuvent nous aider a 
rendre la structure du logiciel plus lisible, il s'agit neanmoins d' operations lourdes, a 
manier avec precaution. 



Le pattern proxy 



Le protocole d'utilisation d'un objet peut s'averer complexe par rapport aux services 
effectivement rendus par celui-ci pour l'une ou 1' autre des raisons suivantes : 
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• Objet distant. L'utilisation de ses services presuppose 1' initialisation d'une communi- 
cation via un protocole specifique (RMI, HOP, SOAP, etc.). 

• Acces controles a l'objet. La securite du logiciel s'impose a certains objets critiques, 
et l'appel de leurs methodes est conditionne par un niveau d'autorisation suffisant. 

• Objet couteux a instancier. Une strategie de creation des instances est necessaire 
pour optimiser les performances du logiciel. 

Le design pattern proxy masque la complexite d' utilisation d'un objet en presentant une 
interface simplifiee. II encapsule tout ou partie du protocole d' acces a l'objet dont il 
prend en charge les aspects techniques. Idealement, un proxy se presente comme un 
POJO (Plain Old Java Object), c'est-a-dire un objet Java elementaire, permettant un 
acces simplifie a un composant. 

Le schema UML de la figure 6.4 illustre l'utilisation de ce design pattern dans le cadre de 
la refonte des acces a un objet distribue. 



Avant 



Client 



Composant 1 



Composant 2 



Serveur 



] 



] 



Composant 3 



Les composants du client ont conscience de la nature L\ 
distribute du composant du serveur qu'ils utilisent. 
La mecanique de communication avec le serveur est 
implementee dans chacun d'eux. 



Figure 6.4 

Refonte avec le design pattern proxy 
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Le composant distant est pergu comme un composant 
local par ses utilisateurs grace au proxy. 
Seul le proxy implemente la mecanique de communication 
avec le serveur. 



K 
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Gains attendus et risques a gerer 



En simplifiant le protocole d' utilisation d'un objet, le design pattern proxy facilite la 
comprehension de ses interactions avec ses utilisateurs. Par exemple, pour les objets 
distribues, il masque la mecanique de communication, rendant les changements a ce 
niveau transparents pour les utilisateurs du proxy. 

Les risques lies a l'utilisation de ce design pattern dans le cadre d'un refactoring varient 
en fonction de la nature du proxy. Par exemple, dans le cadre d'un proxy d'acces a un 
objet distribue, une grande quantite de code peut etre impactee au niveau des utilisateurs 
de la classe masquee par le proxy. II est done necessaire de realiser une analyse d'impacts 
pour estimer la portee des modifications. 

Moyens de detection des cas d'application 

Les cas d' utilisation les plus evidents pour le design pattern proxy au sein d'un logiciel 
existant sont les objets distribues, aisement identifiables dans la mesure ou ils dependent 
d'API techniques specifiques (RMI, EJB, etc.). Loutil de recherche de la plupart des 
environnements de developpement permet de les trouver sans difficulte majeure. 

Les autres cas d'utilisation sont beaucoup plus difficiles a detecter sans une analyse. 
Dans le cas du controle d'acces, il peut s'agir d'extraire des objets la problematique de 
securite pour l'isoler dans un proxy, decouplant ainsi la gestion de la securite des aspects 
fonctionnels. Dans le cas des objets couteux a instancier, un passage en revue des objets 
les plus complexes peut permettre d'identifier rapidement de bons candidats. 

Modalites d'application et tests associes 

La mise en place d'un proxy est relativement simple. La premiere etape consiste a definir 
l'interface du proxy. Celle-ci est un sous-ensemble, voire la totalite, des methodes de 
l'objet masque par le proxy. Pour assurer la consistance entre proxy et objet masque, ces 
deux classes doivent implementer l'interface ainsi definie. 

La classe proxy est ensuite creee. Chaque methode de l'interface doit etre implementee. 
Cette implementation depend du type de proxy recherche. Pour un proxy de controle 
d'acces, il s'agira de verifier que l'appelant a bien les autorisations necessaires avant 
d'appeler la methode correspondante dans l'objet masque, etc. Une fois le proxy deve- 
loppe, il faut le tester unitairement en simulant un objet utilisant ses services. 

Pour terminer, nous devons replacer les appels a l'objet masque par des appels au proxy. 
A cette fin, une serie de tests de non-regression doit etre validee sur le code originel avant 
la modification des appels. Une fois la modification effectuee, la serie de tests est rejouee 
pour detecter d'eventuels problemes. 

Exemple de mise en ceuvre 

Supposons que, dans un logiciel de gestion commerciale dont nous avons la mainte- 
nance, la securite soit geree directement dans les objets metier. La classe Contrat aurait 
1' allure suivante : 
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package fr.eyrol les . exemples. patterns. proxy; 
public class Contrat { 

public ContratUnt pNumero) { 
Utilisateur u = Session. getUtil isateur( ) ; 
if (Gestionnai reDroits.aDroitCreation(u) ) { 

// Creation d'un nouveau contrat 
} else { 

throw new Viol ationAccesException(u) ; 
) 
) 

public void supprimeO { 
Utilisateur u = Session. getUtil isateur( ) ; 
if (Gestionnai reDroits.aDroitSuppression(u) ) { 

// suppression du contrat 
) else { 

throw new Viol ationAccesException(u) ; 
) 
) 

public void enregistreO { 
Utilisateur u = Session. getUtil isateur( ) ; 
if (Gestionnai reDroits.aDroitEcriture(u) ) { 

// enregistrement 
} else { 

throw new ViolationAccesException(u) ; 
} 
} 
} 

Afin de bien dissocier la problematique technique de controle des droits du reste de la 
classe metier Contrat, il est interessant d'employer le design pattern proxy. Le code de 
Contrat s'en trouve simplifie, et la maintenance de la securite peut se faire independamment 
du reste. 

Apres avoir mis au point un jeu de tests pour detecter d'eventuelles regressions suite a 
1' application du design pattern, nous pouvons creer 1' interface commune au proxy et a la 
classe Contrat : 

public interface IContrat { 
publ ic void supprimet ) ; 
public void enregistreO; 

} 

Nous creons ensuite la classe ContratProxy. Celle-ci consiste en une implementation de 
l'interface IContrat a partir de l'extraction du code gerant le controle d'acces dans la 
classe Contrat : 
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public class ContratProxy implements IContrat { 
private Contrat contrat; 

public Contratd'nt pNumero) { 
Utilisateur u = Session. getUtil isateur( ) ; 
if (GestionnaireDroits .aDroiCreation(u) ) { 

contrat = new Contrat(pNumero) ; 
} else { 

throw new ViolationAccesException(u) ; 



public void supprimeO { 
Utilisateur u = Session. getUtil isateur( ) ; 
if (GestionnaireDroits.aDroitSuppression(u) ) 

contrat. supprimeO ; 
} else { 

throw new ViolationAccesException(u) ; 



public void enregistreO ( 
Utilisateur u = Session. getUtil isateur( ) ; 
if (GestionnaireDroits.aDroitEcriture(u) ) 

contrat.enregistre( ); 
} else { 

throw new ViolationAccesException(u) ; 



Afin d'assurer la consistance entre la classe et son proxy, il est necessaire de supprimer 
tout le code de controle d'acces dans la classe Contrat et de lui faire implementer l'inter- 
face IContrat : 

package f r.ey roll es.exemples. patterns. proxy ; 
public class Contrat implements IContrat! 

public Contratd'nt pNumero) { 
// Creation d'un nouveau contrat 



public void supprimeO { 
// suppression du contrat 



public void enregistreO 
// enregistrement 
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Une fois cette operation terminee, le jeu de tests doit etre modifie pour utiliser le proxy et 
non la classe Contrat directement. En l'executant, d'eventuels problemes d' implementation 
du design pattern pourront etre detectes. 

Pour finir, les references a la classe Contrat doivent etre remplacees par des references a 
IContrat, separant ainsi dans le code 1' implementation de l'interface. Les creations 
d'instances de Contrat doivent ensuite etre remplacees par des creations d'instances de 
ContratProxy. Pour minimiser les risques de regression lors de cette etape, des tests 
devront etre mis au point sur le code originel puis rejoues sur la version refondue. 

Grace au design pattern proxy, nous avons clairement separe les problematiques de secu- 
rite des problematiques metier de la classe Contrat. Leur maintenance et leurs evolutions 
respectives s'en trouvent d'autant facilities. 

Le pattern fagade 

Au sein d'un logiciel, les differents traitements pourrendre les services attendus sontrepartis 
au sein d'une multitude d'objets. Les traitements repondent a des problematiques tres 
variees, pouvant etre fonctionnelles ou techniques. Generalement, chaque problematique 
est adressee par un sous-systeme du logiciel. Un service pouvant impliquer plusieurs 
problematiques, les liens entre les differents sous-systemes peuvent devenir tres nombreux 
et difficilement gerables. 

Le design pattern facade vise a simplifier l'acces a un ensemble d'objets formant un 
sous-systeme en fournissant a l'exterieur une interface unifiee, sous forme d'une ou de 
plusieurs classes, masquant la complexite liee a la manipulation de cet ensemble. 

Ce design pattern est particulierement utile pour marquer clairement les limites de chaque 
sous-systeme. Typiquement, nous l'utilisons pour isoler les differentes couches techni- 
ques et fonctionnelles du logiciel. Pour que le sous-systeme soit correctement isole, les 
dependances doivent etre unidirectionnelles, de l'exterieur vers la fagade. 

Le schema UML de la figure 6.5 illustre 1' utilisation de ce design pattern dans le cadre 
d'une refonte. 

Gains attendus et risques a gerer 

En ameliorant la separation des sous-systemes entre eux, nous facilitons la comprehension 
de l'organisation du logiciel et la maintenance de chaque sous-systeme puisque la facade 
masque les details de 1' implementation de ce dernier. 

L application de ce design pattern est cependant une operation lourde, car les relations 
entre les objets sont directement impactees. Dans le cadre d'un projet de refactoring, il est 
preferable d'utiliser ce design pattern de maniere chirurgicale et progressive, sous-systeme 
par sous-systeme. 
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UtilisateuM 



Utilisateur2 



Sous-systeme 



Objet2 



Obiet3 




Utilisateur3 



Le sous-systeme ne presente pas une interface unique L\ 
d'acces. Les details de son implementation sont 
visibles du reste du logiciel. 



Apres 




Le sous-systeme presente un point d'acces unique 
permettant de decoupler service rendu et implementation 



T\ 



Figure 6.5 

Refonte avec le design pattern facade 

II peut etre utile de mettre en place des facades sur lesquelles reposeront les nouveaux 
developpements. Celles-ci peuvent etre pensees de maniere a etre non intrusives vis-a-vis 
du sous-systeme et autoriser deux modes de fonctionnement : soit Faeces direct aux classes 
du sous-systeme (ancien mode), soit l'acces via la facade (nouveau mode). Ce mode de 
fonctionnement implique une double maintenance et doit etre considere comme une 
solution palliative. La refonte de l'existant pour utiliser exclusivement la facade doit 
done etre planifiee. 



Moyens de detection des cas d'application 

Les metriques de couplage permettent d' identifier les relations trop fortes entre sous- 
systemes. Bien entendu, cela suppose d'etre capable de savoir quelle classe appartient a 
quel sous-systeme, ce qui n'est pas forcement evident si le logiciel a ete mal concu, 
notamment si les packages ne sont pas representatifs du decoupage des sous-systemes. 

Une autre methode consiste a analyser les documents de conception ou de retroconception, 
notamment les diagrammes de classes, afin d'identifier les sous-systemes du logiciel et la 
nature des relations qu'ils entretiennent entre eux. 
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Modalites d'application et tests associes 

Au prealable, il est necessaire de delimiter le sous-systeme dont nous voulons masquer les 
details d' implementation. Ses interactions avec l'exterieur doivent etre listees et analysees 
afin de les formaliser au sein de la facade. 

Cette formalisation doit etre accompagnee d'une serie de tests permettant de valider le 
bon fonctionnement de la facade. 

La facade peut se materialiser sous la forme d'une ou de plusieurs classes offrant des 
services a l'exterieur. La facade doit masquer au maximum les details d' implementation 
du sous-systeme qu'elle couvre. 

Ce design pattern remettant en cause les liens qui existent entre le sous-systeme et ses 
utilisateurs, nous conseillons de n'utiliser la facade qu'avec les evolutions introduites 
dans le logiciel. Le code existant conservant ainsi ses liens avec les composants du sous- 
systeme, nous diminuons les risques de mise en oeuvre de ce design pattern tres structurant 
pour un logiciel. Une fois son fonctionnement stabilise avec les evolutions, son utilisation 
peut etre generalisee a l'ensemble du logiciel. 

Exemple de mise en oeuvre 

Reprenons la classe Contrat utilisee dans l'exemple de mise en oeuvre du design pattern 
proxy. Supposons que les methodes supprime et enregi stre accedent directement a la base 
de donnees via JDBC et qu'il en aille de meme pour les autres objets metier, comme 
C1 1 ent ou Commerci al . Dans ce cas de figure, nous avons un lien direct entre les objets metier 
et le sous-systeme JDBC. Les problematiques techniques liees a la persistance des donnees 
sont melangees avec les problematiques fonctionnelles adressees dans les objets metier. 

Afin de simplifier le code des objets metier, il peut etre interessant d'en extraire la gestion 
de la persistance et de la sous-traiter a une facade chargee de la communication avec le 
sous-systeme JDBC pour assurer ce service. 

Pour la classe Contrat, cette operation consiste a extraire le code des methodes a supprimer 
et enregistrer pour les placer dans une nouvelle classe representant la facade : 

package fr.eyrol les . exemples. patterns. facade; 

// Imports 

public class FacadePersistance ( 

public void supprimeContrat(Contrat pContrat) { 

//Code extrait et adapte de la methode Contrat. supprime 
} 

public void enregistre(Contrat pContrat) { 

//Code extrait et adapte de la methode Contrat. enregistre 
} 
//... 
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Ann de decoupler 1' implementation, representee par FacadePersi stance, de son interface 
et faciliter les tests unitaires ainsi que les evolutions de la couche persistance, nous 
pouvons definir une interface I FacadePersi stance reprenant les methodes publiques de la 
classe et devant etre implementee par cette derniere : 

package f r.eyrol les.exemples. patterns. fa cade; 

public interface IFacadePersistance { 

public void supprimeContrat(Contrat pContrat); 
public void enregistre(Contrat pContrat); 

} 

Les references a la facade devront etre du type IFacadePersistance au lieu de FacadePer- 
si stance, permettant d' avoir plusieurs strategies de persistance, par exemple, dans le cas 
d'une application nomade (voir le design pattern etat). 

Une fois la facade achevee, nous devons la tester unitairement avant de l'utiliser pour les 
nouveaux developpements. 

Ensuite, pour ne pas avoir a modifier massivement le code du logiciel, les methodes 
supprime et enregistre de la classe Contrat sont modifiees afin d'appeler la facade, au 
lieu d'effectuer le traitement elles-memes, et d'eviter une double maintenance, 
couteuse et source d'erreurs. Elles doivent etre marquees comme etant obsoletes (tag 
javadoc ©deprecated) : 

package f r.eyrol les.exemples. patterns. fa cade; 

import java.util .Date; 

public class Contrat { 

int numero; 
Date dateEffet; 

public int getNumeroO { 
return numero; 



public void setNumeroO'nt pNumero) 
numero = pNumero; 



public Date getDateEffet( ) 
return dateEffet; 



public void setDateEffet(Date pDateEffet) 
dateEffet = pDateEffet ; 



Techniques avancees de refactoring 

Partie II 



* ©deprecated 
*/ 

public void supprimeO { 

facadePersi stance. suppri me (this) ; 
} 
/** 

* ©deprecated 
*/ 

public void enregistreO ( 

f acadePe rs i stance. en regi st re (this) ; 
} 



Afin de detecter d'eventuelles regressions, un jeu de tests sur les methodes modiflees, 
prealablement valide sur le code originel, doit etre utilise. 

Des operations de nettoyage du code devront etre planifiees par la suite pour remplacer 
les appels aux methodes obsoletes par des appels directs a la facade. Chaque operation 
devra etre accompagnee de tests de non-regression. 

Une fois le code totalement nettoye, la classe Contrat pourra etre allegee en supprimant les 
methodes obsoletes. Dans notre cas, Contrat devient un JavaBean elementaire uniquement 
dote des methodes getters et setters sur ses attributs : 

package fr.eyrol les . exemples. patterns. facade; 

import java.util .Date; 

public class Contrat { 

int numero; 
Date dateEffet; 

public int getNumeroO { 
return numero; 



public void setNumeroO'nt pNumero) 
numero = pNumero; 



public Date getDateEffet( ) 
return dateEffet; 



public void setDateEffet(Date pDateEffet) 
dateEffet = pDateEffet ; 
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Grace a 1' application du design pattern facade, les relations avec le sous-systeme JDBC 
sont centralisees et apparaissent sous forme de services metier, plus faciles a manipuler, 
vis-a-vis des sous-systemes de plus haut niveau. La gestion de la persistance peut evoluer 
sans pour autant perturber le reste de 1' application du moment que le contrat de la facade 
reste constant. 



Le pattern adaptateur 

Au cours de la vie d'un logiciel, certaines classes sont susceptibles de voir leur contrat 
vis-a-vis de l'exterieur profondement modifie (changement de la signature de methodes, 
suppression de methodes, etc.). Pour gerer ces modifications de contrat, deux strategies 
sont possibles : 

• Modifier 1' ensemble des classes utilisatrices, ce qui peut s'averer rapidement redhibitoire. 

• Chercher a rester parfaitement compatible avec les anciens contrats, d'ou une complexite 
accrue de la classe au fil des evolutions. 

Le design pattern adaptateur permet de maintenir differentes versions d'une me me classe 
au sein d'un logiciel. Pour cela, il suffit de creer une classe par version. L' organisation de 
ces classes depend du contexte. Ann de faciliter la reutilisation entre les versions et leur 
substitution aupres des classes utilisatrices (passage d'une version n a une version n + 1), 
nous utilisons generalement les mecanismes d'heritage : une classe mere abstraite 
concentrant le contrat de base commun a toutes les versions et une succession de sous- 
classes (une par version). 

Le schema UML de la figure 6.6 illustre l'utilisation de ce design pattern dans le cadre 
d'une refonte. 

Gains attendus et risques a gerer 

L'utilisation de ce design pattern est recommandee plutot a priori, c'est-a-dire au 
moment ou nous faisons evoluer le contrat d'une classe dans le cadre d'une maintenance 
evolutive, qu'a posteriori, lors d'un refactoring, ou sa mise en ceuvre est complexe. Son 
application peut-etre justifiee dans le cas de classes rendues « obeses » et difficilement 
maintenables pour garantir une compatibilite ascendante complexe. Cette technique doit 
etre vue comme un moyen de lisser le cout d'une migration a une nouvelle version et non 
comme une fin en soi. 

Les risques associes a l'utilisation de ce design pattern a posteriori dans le cadre d'un 
refactoring sont importants, car 1' implementation de la classe originelle est modifiee en 
profondeur. Le risque est proportionnel au nombre de versions differentes et a 1' impor- 
tance de leurs differences. Par ailleurs, il faut etre capable de bien faire le lien entre une 
version donnee et ses utilisateurs. 
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L'execution d'operation 1 L\ 

genere une exception runtime. 
Le code d'operation 3 est 
simplifie. 



L'execution d'operation 2 L\ 
genere une exception runtime 
Le code d'operation 3 est 
simplifie. 



Figure 6.6 

Refonte avec le design pattern adaptateur 



Moyens de detection des cas d'application 

Les cas d'application de ce design pattern peuvent etre detectes grace a plusieurs metriques : 

• Nombre de versions differentes d'une meme classe dans l'outil de gestion de confi- 
guration. Une classe ayant un grand nombre de versions a une probabilite non negligeable 
de vehiculer des traitements pour assurer la compatibilite avec le code reposant sur ses 
versions anterieures. 
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• Classes devenues obeses (dont les metriques de dimension sont devenues tres impor- 
tantes au fil du temps). Nous pouvons observer dans ce type de classe des phenomenes 
de sedimentation du code, dont revolution a ete guidee par des ajouts fonctionnels non 
controles du point de vue de la conception. 

• Classes ayant un fort couplage afferent. Le cout de modification du contrat de ce 
type de classe etant tres important, elles peuvent se complexifier afin de garantir une 
compatibilite ascendante. 

Bien entendu, les metriques ne sont qu'un indice, et l'opportunite d'application du design 
pattern adaptateur doit etre confirmee par une analyse du code de la classe selectionnee 
quantitativement. 

Modalites d'application et tests associes 

La premiere etape consiste a identifier le nombre de versions differentes cohabitant au 
sein de la classe originelle ainsi que les methodes implementees pour chacune d' elles. 
La version en cours doit etre isolee des autres afin de bien voir les differences. 

Une serie de jeux de tests doit etre definie et validee sur la classe existante pour chaque 
version identifiee. 

La classe originelle doit etre transformee en classe abstraite. Les methodes conservees a 
seule fin de compatibilite avec les versions anterieures doivent etre marquees comme 
etant obsoletes. Pour cela, nous utilisons le tag javadoc ©deprecated. Les developpeurs 
sont avertis de la sorte que ces methodes ne doivent plus etre utilisees. 

Ensuite, chaque version est isolee dans une classe concrete heritant de la classe originelle. 
Au sein de cette classe, les methodes utilisees par cette version doivent etre implemen- 
tees en extrayant le code des methodes correspondantes dans la classe mere ainsi que les 
attributs necessaires a leur execution. In fine, la classe mere devient vide de toute imple- 
mentation, et ses methodes sont declarees abstraites, hormis pour les traitements communs 
a toutes les versions. 

Les methodes qui ne doivent pas etre utilisees pour une version donnee, par exemple, les 
methodes creees dans une version ulterieure et incompatibles avec les anciens traitements, 
generent une exception d'execution (Runtime Exception). 

Les jeux de tests precedemment crees doivent etre modifies afin d'utiliser la classe 
concrete correspondant a la version dont ils doivent tester la non-regression. Cette operation 
faite, ils doivent etre executes pour de teeter d'eventuels problemes. 

Pour terminer, il faut remplacer les creations d'instances de la classe originelle (generant 
des erreurs de compilation puisqu'elle est devenue abstraite) par des creations d'instan- 
ces de ses sous-classes concretes. II est important de s' assurer que la version selectionnee 
repond bien aux besoins. S'il s'avere qu'une classe utilisatrice repose sur plusieurs 
versions differentes, nous selectionnons la version la plus recente et remanions le code en 
consequence. Si la classe originelle est chargee dynamiquement (via Class.forName), il 
faut modifier la mecanique de chargement en consequence. 
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Avant d'effectuer ces modifications, il est important de definir et valider des tests de non- 
regression sur le code originel. Ces tests seront rejoues une fois le code modifie. 

Exemple de mise en ceuvre 

Avec le design pattern facade applique a la classe Contrat, nous avons extrait la gestion 
de la persistance des donnees de cette derniere pour la placer dans FacadePersi stance. 
Pour ne pas perturber l'existant, les methodes supprime et enregistre ont ete maintenues 
dans la classe Contrat. 

Afin de lever toute ambiguite, il peut etre interessant de separer les versions avec et sans 
facade. Pour cela, nous definissons en premier lieu la classe Contrat comme etant 
abstraite (les methodes obsoletes restent marquees par le tag javadoc ©deprecated) : 

package fr.eyrol les . exemples. patterns. adapt a teur; 

public abstract class Contrat { 

int numero; 
Date dateEffet; 

public int getNumeroO { 
return numero; 



public void setNumeroO'nt pNumero) 

numero = pNumero; 
} 

public Date getDateEffet( ) { 
return dateEffet; 



public void setDateEffet(Date pDateEffet) 
dateEffet = pDateEffet ; 



/** 

* ©deprecated 
*/ 

public abstract void supprimeO; 

* ©deprecated 
*/ 

public abstract void enregistre( ) ; 



//. 



Avant d'aller plus loin, il nous faut definir et valider un jeu de tests sur le code utilisant 
Contrat afin de detecter d'eventuelles regressions. 
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Nous creons ensuite deux sous-classes, ContratLeger et ContratLourd. La premiere correspond 
a la version avec facade et la seconde a la version sans facade. 

Le code de ContratLourd consiste en une extraction des methodes obsoletes dans la classe 
originelle : 

package f r.eyrol les.exemples. patterns. adapt a teur; 

public class ContratLourd extends Contrat { 

/** 

* ©deprecated 
*/ 

publ ic void supprimet ) { 

facadePersi stance. supprime( this) ; 
} 
/** 

* ©deprecated 
*/ 

public void enregistreO { 

f acadePer s i stance. en regi st re (this) ; 
} 

} 
ContratLeger, pour sa part, ne doit pas implementer les methodes obsoletes : 

package f r.eyrol les.exemples. patterns. adapt a teur; 
public class ContratLeger extends Contrat ( 

/** 

* ©deprecated 
*/ 

public void supprimet ) { 

// Generation d'une exception d'execution 

throw new MethodeObsoleteExceptionCContratLeger.supprime" ) ; 

} 

/** 

* ©deprecated 
*/ 

public void enregistreO { 

throw new MethodeObsoleteException( "ContratLeger.enregistre") ; 
} 

} 

ContratLeger etant reserve aux futurs developpements, les creations d'instance de la classe 
Contrat originelle sont remplacees par des creations d'instances de la classe ContratLourd. 
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II faut s'assurer par ailleurs que les creations d'instances dynamiques tiennent compte de 
ce changement. 

Pour terminer, il faut verifier 1' application de ce design pattern en rejouant le jeu de tests 
mis au point sur le code existant. 

Grace a 1' application du design pattern adaptateur, nous pouvons migrer progressivement 
le code existant reposant sur des objets metier lourds vers notre nouvelle architecture. 

Conclusion 

Ce chapitre a illustre la mise en oeuvre de plusieurs design patterns majeurs dans le cadre 
du refactoring. 

Ces techniques complexes remanient en profondeur une partie de la structure du logiciel. 
D'une maniere generale, elles ne peuvent etre utilisees dans le cadre d'une maintenance 
classique, sauf si leur perimetre reste limite. 
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Refactoring avec la POA 
(programmation 
orientee aspect) 



La POA (programmation orientee aspect), ou AOP (aspect-oriented programming), est 
un nouveau paradigme dont les fondations ont ete definies au centre de recherche Xerox, 
a Palo Alto, au milieu des annees 1990. Par paradigme, nous entendons un ensemble de 
principes qui structurent la maniere de modeliser les applications informatiques et, en 
consequence, la facon de les developper. 

Elle a emerge a la suite de differents travaux de recherche, dont l'objectif etait d'amelio- 
rer la modularite des logiciels afin de faciliter la reutilisation et la maintenance. 

La POA ne remet pas en cause les autres paradigmes de programmation, comme l'approche 
procedurale ou l'approche objet, mais les etend en offrant des mecanismes complementaires 
pour mieux modulariser les differentes preoccupations d'une application. 

Ainsi, il existe des outils de POA compatibles avec les langages orientes objet, voire 
proceduraux, ce qui permet leur utilisation au sein de logiciels existants. Dans le contexte 
de ce chapitre, nous utilisons AspectJ, qui est l'outil de POA compatible Java/J2EE le 
plus utilise a ce jour. 

Meme si l'utilisation a grande echelle de la POA n'est pas encore d'actualite, il nous 
semble interessant de presenter quelques techniques de refactoring qui l'utilisent, car ses 
concepts novateurs permettent d'aller plus loin dans 1' amelioration de la qualite d'un 
logiciel. 
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Pour les lecteurs qui ne connaitraient pas ce nouveau paradigme de progr animation, la 
premiere partie du chapitre donne une vision succincte des notions cles de la POA. Les 
exemples fournis par la suite pour chaque technique de refactoring sont volontairement 
simples arin d'etre comprehensibles du neophyte. Nous invitons ceux qui desireraient en 
savoir plus sur la POA a lire l'ouvrage Programmation orientee aspect pour Java/J2EE, 
publie en 2004 aux editions Eyrolles. 



AspectJ 

Definie en 1 996 par Gregor Kiczales et son equipe du centre de recherche Xerox PARC de Palo Alto en 
Califomie, la POA a rapidement ete mise en oeuvre dans un langage de programmation, AspectJ, dont 
les premieres versions ont ete disponibles en 1998. Depuis cette date, AspectJ est reste le langage de 
POA le plus utilise. 

AspectJ etend le langage Java avec de nouveaux mots-cles permettant de programmer des aspects. 
Depuis decembre 2002, le projet AspectJ a quitte le PARC et rejoint la communaute Open Source Eclipse. 
AspectJ existe en version ligne de commande ou sous forme de plug-in pour la plupart des environnements 
de developpement Java. Dans le cadre de cet ouvrage, nous utilisons le plug-in AJDT (AspectJ Develop- 
ment Tools) pour I'environnement de developpement Eclipse (disponible sur http://eclipse.org/ajdt/). 



Principes de la programmation orientee aspect 

Nous presentons brievement dans cette section les problematiques adressees par la POA 
afin de montrer en quoi ce nouveau paradigme ameliore la modularite du code par 
rapport a d'autres approches. Nous introduisons ensuite les differentes notions de la POA 
permettant d'implementer de nouvelles techniques de refactoring. 

Les problematiques adressees par la POA 

Le principe de la POA est de modulariser les elements logiciels mal pris en compte par 
les paradigmes classiques de programmation. En 1' occurrence, la POA se concentre sur 
les elements transversaux, c'est-a-dire ceux qui se trouvent dupliques ou utilises dans un 
grand nombre d'entites, comme les classes ou les methodes, sans pouvoir etre centralises 
au sein d'une entite unique. 

Lidee sous-jacente est d'ameliorer ce que nous appelons la separation des preoccupa- 
tions. Les developpeurs d'application ont generalement plusieurs preoccupations a pren- 
dre en compte dans leurs developpements. Ces preoccupations peuvent etre divisees en 
deux categories : les preoccupations fonctionnelles, qui correspondent au coeur de metier 
de 1' application, et les preoccupations techniques, qui sont liees a I'environnement 
d'execution de 1' application. 

En programmation orientee objet, ces deux preoccupations entretiennent generalement 
des liens etroits, car les preoccupations d'ordre technique sont, dans beaucoup de cas, 
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transversales. En consequence, le code metier est souvent alourdi par des preoccupations 
d'ordre technique. 

Avec les EJB, notamment les EJB Entity CMP, un premier niveau de separation des 
preoccupations a ete atteint. Un grand nombre d' aspects techniques sont en effet pris en 
charge sous forme de descripteurs de deploiement (mapping objet-relationnel, etc.) et 
n'apparaissent plus dans le code metier. La maintenance en est d'autant facilitee. 

La POA va au-dela de ces premieres tentatives en offrant des mecanismes generiques 
pour modulariser les elements transversaux des logiciels, comme nous le verrons dans les 
sections suivantes. 



Les notions introduites par la POA 

Plusieurs notions nouvelles sont introduites par la POA. Outre la notion d'aspect, equiva- 
lent de la notion de classe en POO, les notions de point de jonction, de coupe, de code 
advice et d' introduction sont les constituants de base de la notion d'aspect, que nous 
detaillons a la fin de cette section. 

La notion de point de jonction et de coupe 

La POA modularisant des elements transversaux, il est necessaire de specifier les 
endroits du code ou ils s'inserent. Pour cela, la POA utilise la notion de point de jonction 
(join point), qui designe des endroits caracteristiques dans le code. 

II existe differents types de points de jonction, associes aux entites de la POO ou d'un 
autre paradigme : 

• appel ou execution de methodes ou de constructeurs ; 

• generation d' exceptions ; 

• lecture ou ecriture d'attributs, etc. 

Nous aurions pu imaginer utiliser le numero de ligne (dans le code) comme point de 
jonction, mais celui-ci est beaucoup trop fluctuant pour pouvoir etre utilise efficacement 
puisqu'il change a chaque modification du code. 

Ces points de jonction utilisent generalement un langage a base d'expressions regulieres 
pour designer ces endroits caracteristiques. Par exemple, le point de jonction AspectJ 
cal 1 designe les appels a une ou plusieurs methodes qui lui sont specifiers en parametres. 

Une coupe (pointcut) est un ensemble de points de jonction combines a des operateurs 
logiques (&&, ||, !). Par exemple, la coupe AspectJ suivante designe les appels a 
uneMethode ou uneAutreMethode de la classe UneClasse : 

■ pointcut coupeO : calKvoid UneClasse. uneMethode( ) ) | 
cal 1 (void UneClasse.uneAutreMethode( ) ) ; 

Une coupe seule n'est pas d'une grande utilite. C'est son couplage avec des codes advice 
qui permet d'inserer les elements transversaux dans le code executable. 
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Une coupe peut etre abstraite, c'est-a-dire uniquement declaree, sa definition etant deleguee 
aux descendants de 1' aspect auquel elle appartient : 

abstract pointcut coupeO; 

Elle peut aussi etre privee, protegee ou publique, a l'instar des methodes en POO : 

I private pointcut coupeO : calltvoid UneClasse.uneMethode( )) | 
cal 1 (void UneClasse.uneAutreMethodet ) ) ; 

La notion de code advice 

Une fois que nous avons defini la coupe ou doivent s'inserer les elements transversaux, 
nous devons definir leur contenu. Ce contenu se presente sous forme de code advice 
(advice). Ces codes advice, qui ne sont pas sans rappeler la notion de methode en oriente 
objet, sont de plusieurs types. Les trois principaux que nous utilisons dans ce chapitre 
sont les suivants : 

• before : l'element s'insere avant l'endroit designe par la coupe. 

• after : l'element s'insere apres l'endroit designe par la coupe. 

• around : l'element s'insere en lieu et place du code se trouvant a l'endroit designe par 
la coupe. 

Pour ce dernier type, il est possible d'executer le code remplace en utilisant le mot-cle 
proceed d'AspectJ. 

Les codes advice before et after 

Si nous reprenons la coupe precedente, nous pouvons definir les codes advice suivants : 

beforeO : coupeO { 

System. out. printlnt "execute avant l'endroit designe"); 
} 
afterO : coupeO ( 

System. out. printlnt "execute apres l'endroit designe"); 
} 

L' utilisation de ces deux codes advice revient a ecrire le code suivant en Java pur : 

I System. out. printlnt "execute avant l'endroit designe"); 
uneMethodet ) ; 
System. out. printlnt "execute apres l'endroit designe"); 

Nous pouvons constater que la mise en place de codes advice before et after est tres simple. 
II faut noter qu'il n'y a pas ici de code advice de type around. En effet, pour une meme 
coupe, la presence d'un code advice de ce type interdit l'utilisation des deux autres. 

Le code advice around 

Le code advice around est plus complexe a manipuler puisqu'il remplace du code suscep- 
tible de produire un resultat, par exemple, une fonction renvoyant un booleen. Si nous 
reprenons 1' exemple precedent, nous pouvons le reecrire de la maniere suivante : 
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void around( ) : coupe( ) { 

System. out. printlnC'avant l'execution du code remplace"); 

proceedt ) ; 

System. out. printlnC'apres l'execution du code remplace"); 
} 

Nous constatons que, contrairement aux deux autres types, un code advice around doit 
specifier un type de valeur de retour (en gras dans le code). En l'occurrence, il s'agit de 
void, car la coupe n'intercepte que les appels a des methodes ne renvoyant pas de valeur. 

Si ces deux methodes renvoyaient chacune un booleen, par exemple, le code serait le 
suivant : 

boolean aroundO : coupeO { 

System. out. printlnC'avant l'execution du code remplace"); 

boolean resultat = proceedO; <— Q 

System. out. printlnC'apres l'execution du code remplace"); 

return resultat; <— © 
} 

Ainsi, proceed renvoie le resultat produit par le code remplace (repere 0). Celui-ci est 
recupere pour etre retourne par le code advice (repere Q), faute de quoi le logiciel ne 
fonctionnerait plus. L'utilisation de proceed n'est pas obligatoire, et le code advice peut 
completement reecrire le code remplace. 

Les codes advice declare warning et declare error 

AspectJ propose deux autres types de code advice utilises dans ce chapitre : declare 
warning et declare error. Ces codes advice tres simples permettent de generer des avertis- 
sements ou des erreurs de compilation designes par une coupe. Un exemple en est fourni 
par la technique d'analyse d'impacts que nous decrivons plus loin. 

La notion d'introduction 

L' introduction (static crosscutting) consiste a enrichir une classe ou une interface en 
introduisant en son sein de nouveaux elements : 

• Specialisation d'une classe (si elle ne possede pas deja une classe mere). 

• Implementation d' interface. 

• Ajoutde methodes ou d'attributs. 

Ces operations s'effectuent au sein d'un aspect et n'impactent pas le code de la classe ou 
de l'interface cible. Un exemple est fourni dans la technique consistant a definir une 
implementation par defaut pour une interface. 

La notion d'aspect 

Un aspect est une notion similaire a celle de classe en POO en terme de granularite. A 
l'instar de cette derniere, l'aspect supporte l'heritage et 1' abstraction. II peut comporter 
des methodes et des attributs prives, proteges ou publics, statiques ou non. 
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Un aspect possede des instances au meme titre qu'une classe. Le mecanisme d'instancia- 
tion par defaut d'AspectJ suit le principe du singleton : une seule instance de l'aspect est 
creee pour l'ensemble du logiciel. II existe d'autres mecanismes d'instanciation, mais ils 
depassent le cadre de cet ouvrage. 

Le code suivant montre un aspect abstrait heritant d'un autre aspect et possedant deux 
attributs, dont un statique, ainsi qu'une methode : 

abstract aspect UnAspectAbstrait extends UnAutreAspect { 

private String unAttribut; 

private static int unAttributStatique; 

public void UneMethodeO { 



//. 



) 



Outre le mecanisme d'instanciation, la specificite de l'aspect par rapport a la notion de 
classe est son support des notions de coupes, de codes advice et d' introductions. 

Le code suivant reprend l'exemple de coupe et de code advice utilise precede mment : 

aspect UnAspect { 

private pointcut coupeO : calKvoid UneClasse.uneMethode( ) ) | 
call (void UneClasse.uneAutreMethode( ) ) ; 

beforeO : coupeO { 

System. out. printl nC'execute avant l'endroit designe"); 

) 



after () : coupeO { 

System, out. printl nC'execute apres 
) 



'endroit designe") 



) 



Un aspect a la possibilite d'etre privilegie, c'est-a-dire d'etre en mesure d'acceder a des 
elements prives ou proteges d'une classe. Pour cela, il suffit de faire preceder le mot-cle 
aspect du mot-cle privileged. 

L utilisation de la POA necessite une compilation en deux phases. La premiere est une 
compilation de code Java classique, dans laquelle les elements transversaux ne sont pas 
injectes dans le code executable. La seconde phase, appelee tissage (un compilateur POA 
est souvent appele un tisseur), effectue cette injection de maniere a produire le code 
executable final. 

La capacite d'un aspect a modifier en profondeur le fonctionnement des classes d'un 
logiciel peut poser des problemes dans la comprehension du code. En effet, un deve- 
loppeur manipulant une classe n' aura pas forcement conscience que celle-ci est modifiee 
par un ou plusieurs aspect. Pour combler ce manque, l'environnement de developpement 
utilise est essentiel. 
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Grace au plug-in Eclipse AJDT, le developpeur peut voir aisement les elements impactes 
par un aspect directement dans l'editeur de code, comme l'illustre la figure 7.1. 



package f r . eyrolles . exemples .poa . remplace; 
^public class UneClasse { 

1, 



■*l 



public void uneMethode {) { 
system . out . println ( " log 



- 



<i 



I [ " LOG 

Marqueurs AspectJ 

System. out . print In ( " LOG 
System . out . println ( " LOG 



entrSe uneMethode") ; 
debut traitement x" ) ; 
fin traitement x" ), 
sortie uneMethode") ; 



- 



Figure 7.1 

Marqueurs indiquant V application d'un aspect sur du code 

AJDT permet aussi de visualiser globalement l'impact d'un aspect grace a la perspective 
de visualisation d'aspect (voir figure 7. 2). Pour l'ouvrir depuis Eclipse, selectionnez 
Window/Open perspective/Other puis Aspect Visualization. 
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Figure 7.2 

Visualisation de l'impact de plusieurs aspects sur les classes d'un package 



Nous constatons que laclasse BoiteAOutilsFin estmodifiee par 1' aspect Cache (seul coche 
dans la liste). Cache et CacheCours sont des aspects et sont done remplis de couleur noire. 
Les modalites de creation d'un aspect avec Eclipse sont decrites au chapitre 11. 
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Modularisation des traitements 

Comme indique en debut de chapitre, l'objectif principal de la POA est d'offrir une nouvelle 
dimension de modularisation des traitements en prenant en compte les preoccupations 
transversales de maniere beaucoup plus efficace qu'avec la POO. 

Les techniques de la POA peuvent des lors etre utilisees efhcacement dans le cadre d'un 
projet de refactoring arm d'ameliorer la qualite du logiciel et de faciliter sa maintenance 
ainsi que ses evolutions futures. 

Extraction d'appels 

L' implementation de certaines methodes peut contenir des appels dont la finalite n'a que 
peu de rapport avec sa problematique premiere, augmentant ainsi leur complexite. Par 
exemple, une methode implementant un traitement metier doit appeler un certain nombre 
de methodes d'ordre technique, comme la gestion des traces, etc. 

Un deuxieme cas de figure justifiant l'emploi de l'extraction d'appels est lorsque l'imple- 
mentation de plusieurs methodes repose sur des appels identiques a d'autres methodes, 
comme l'ecriture d'une piste d'audit fiscal, par exemple. En cas de modification de ces 
dernieres, l'ensemble des methodes appelantes doit etre modifie pour en tenir compte. 

Description de la solution 

La solution a ce probleme consiste a extraire les appels aux methodes pour les centraliser 
au sein d'un aspect unique. La methode originelle se trouve ainsi debarrassee de tout lien 
direct avec les methodes extraites. Pour que cette technique fonctionne avec Aspect!, il est 
necessaire que les appels a extraire se situent a des endroits specifiables par une coupe. 

La figure 7.3 illustre le principe de fonctionnement de cette technique. 



Code originel 



Code refondu 



public class UneClasse { 

p ublic void methodeA () { 
methodeTransverse 1 ();„ 



//.. 



methodeTransverse 2 



(^ 



\ 



p ublic void methodeB () { 



methodeTransverse 1 Qr^ 



} 



} 



IL, 

methodeTransverse 2(); 



\ 



public aspect Extraction { 
private pointcut coupe () 

b efore () : coupeQ { 



Figure 7.3 

Extraction d'appels 



methodeTransverse 1() 



} 



} 

a fterQ : coupeQ { 

methodeTransverse 2(); 
} 




public class UneClasse { 
public void methodeA () { 



public void methodeB () { 
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Gains attendus et risques a gerer 

Grace a la centralisation des appels extraits au sein d'un aspect, nous ameliorons la 
comprehension du code dans le premier cas. La methode d'origine est debarrassee 
d' appels a des methodes sans rapport avec sa problematique specifique. Dans le second 
cas, les traitements transversaux sont centralises, facilitant la maintenance s'ils sont 
amenes a evoluer. 

Quel que soit le cas, l'extraction d' appels peut impliquer un grand nombre de methodes 
et de classes. Plus la portee d'un aspect est large, plus sa mise au point est delicate puis- 
que 1' effort de test en depend. Par ailleurs, chaque methode peut apporter des specificites 
dans le format des appels, pouvant rendre 1' aspect complexe afin de les prendre en 
compte. 

Moyens de detection des cas d'application 

La detection des cas d'application necessite une revue de code. Nous pouvons concentrer 
les efforts sur les objets implementant la partie metier du logiciel. En effet, celle-ci 
repose souvent sur des appels aux couches techniques s'averant transversaux, et done 
modularisables grace a la POA. 

Modalites d'application et tests associes 

La premiere etape consiste a determiner le perimetre des appels a extraire pour determi- 
ner la coupe a effectuer et le contenu des codes advice modularisant les appels extraits. 

II est necessaire de mettre au point, si ce n'est deja fait, un jeu de tests permettant de detecter 
d'eventuelles regressions apres la refonte. L'extraction etant une operation strictement 
interne a la methode, elle doit etre totalement transparente vis-a-vis de ses appelants. 

La creation de l'aspect d'extraction necessite deux etapes : la definition de la coupe et la 
definition des codes advice associes. 

La coupe doit contenir 1' ensemble des methodes dont sont extraits les appels. Un code 
advice before doit etre defini si les appels extraits sont executes au debut de l'execution 
des methodes en question. De la meme maniere, un code advice after doit etre defini si 
les appels extraits sont executes a la fin de l'execution des methodes. Ces codes advice 
contiendront les appels en question. 

Apres avoir supprime les appels dans les methodes originelles et tisse l'aspect avec le 
nouveau code, le jeu de tests precedemment defini doit etre employe sur le code refondu 
pour tester son bon fonctionnement. 

Exemple de mise en ceuvre 

Nous donnons comme exemple de mise en oeuvre une classe entrant dans le deuxieme 
cas de figure, e'est-a-dire dont nous pouvons ameliorer la modularisation en centralisant 
un traitement transversal au sein d'un aspect. 
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L'exemple fourni ici, MonBuffer, est une classe encapsulant Java. lang. StringBuffer. 
L'objectif de cette classe est de ne creer une instance de StringBuffer qu'au moment ou 
nous en avons reellement besoin, c'est-a-dire lorsque nous lisons ou modifions son 
contenu pour la premiere fois. Cette technique est appelee 1' initialisation retardee (lazy 
initialization). Elle optimise les performances en retardant au maximum les instanciations 
cofiteuses (dans le cas present, l'instanciation de StringBuffer n'est pas vraiment couteuse, 
mais nous considererons que tel est le cas ici) : 

Le code de la classe MonBuffer est le suivant : 

package fr.eyrol les.exemples.poa.init; 
public class MonBuffer { 

private StringBuffer contenu; <— 

private void initO { <— 

if (contenu==nul 1 ) { 

contenu = new StringBuffer(lOOOO) ; 

} 
) 

public void ajouteAuContenu(String pValeur) { 

initO; <— © 

contenu. append (pValeur) ; 
} 

public void ajouteAuContenuO'nt pValeur) { 

initO; <— 

contenu. append (pValeur) ; 
} 

public String toStringO { 
InitO ; <— O 

return contenu. toStringt ) ; 
} 

) 

Nous constatons que l'unique attribut de cette classe, contenu, n'est initialise ni directe- 
ment, ni par un constructeur (repere 0). L'initialisation est prise en charge par la 
methode init (repere 0), appelee par les methodes sollicitant l'attribut (reperes 0). 

Pour tester le fonctionnement de cette classe, nous avons cree un test unitaire tres simple : 

package fr.eyrol les.exemples.poa.init; 

import junit.framework.TestCase; 

public class MonBufferTest extends TestCase { 

private MonBuffer buffer; 

protected void setUpO throws Exception { 
buffer = new MonBufferO; 
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public void testToString( ) { 

buffer.ajouteAuContenut'test") ; 

assertEqualsC'test" ,buffer.toString( )) ; 
} 

public void testAjouteAuContenuString( ) { 
buffer. ajouteAuContenu( "debut " ) j 
buffer. ajouteAuContenu( "fin" ) ; 
assertEquals( "debut fin" ,buffer.toString( ) ) ; 

} 

public void testAjouteAuContenuint( ) { 
buffer. ajouteAuContenu(20) ; 
buffer. ajouteAuContenu(5) ; 
assertEquals("205" ,buffer.toString( )) ; 



Si nous l'executons sur le code actuel de la classe MonBuffer, nous constatons qu'il ne 
detecte aucune anomalie. Nous reutiliserons ce test unitaire pour valider notre operation 
de refactoring. 

Si nous revenons au code de MonBuffer, nous constatons que les appels a la methode init 
sont systematiques et qu'il est possible de les extraire grace a la POA. 

Pour cela, nous allons derinir un aspect compose d'une coupe et d'un code advice de type 
before. La coupe doit capturer l'ensemble des executions des methodes ayant besoin des 
services de init, en l'occurrence les methodes ajouterAuContenu et toString. Grace a cette 
coupe, nous allons pouvoir effectuer le traitement transversal assure par la methode init 
au travers d'un code advice. Ce dernier doit etre de type before, puisque 1' initialisation 
doit etre effectuee avant toute manipulation de l'attribut contenu. 

L' aspect est implemente sous forme d'aspect interne, car il s'agit ici d'une operation 
strictement interne a la classe. Nous inserons done le code suivant au sein de la classe 

MonBuffer : 

package f r.ey roll es.exempl es.poa.ini t; 
public class MonBuffer { 

static aspect InitRetardee { 

private pointcut initO : 

execution (void MonBuffer. ajouteAuContenu(*) ) 1 1 <— © 
execution (String MonBuffer. toString( )) ; 

before(MonBuffer c) : initO && target(c) { <— © 
c.initt ) ; 
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Le mot-cle static (en gras dans le code) applique a l'aspect indique que celui-ci est 
interne a la classe MonBuffer. 

La coupe init intercepte l'execution des deux methodes ajouteAuContenu (repere O 1 en 
utilisant * pour designer un parametre de type indefini. Le code advice associe recupere 
l'instance de la classe MonBuffer interceptee par la coupe grace au mot-cle target (repere Q) 
et l'utilise pour appeler la methode 1n1 1. 

L aspect interne etant maintenant en place, nous pouvons supprimer les appels explicites 
a init dans les methodes ajouteAuContenu et toString. 

Nous pouvons visualiser 1' interception de l'execution de ces methodes en utilisant la vue 
des references croisees fournie par AJDT et accessible via Window, Show view et Other 
puis en selectionnant Cross References dans le dossier AspectJ. II suffit de double-cliquer 
sur le code advice pour rafraichir la vue avec les informations qui nous interessent. 

La figure 7.4 illustre l'interception des executions pour l'initialisation retardee de MonBuffer. 



Problems. Console I 



Cross References X 



E ^ advises 

•» MonBuffer.a]outeAuConteriu(string) 
■ ►* MonQuffer.ajouteAuContenu(int) 
»» Mon Buff er.toStrtngQ 



Figure 7.4 

Interception des executions pour l'initialisation 

Afin de valider cette operation de refactoring, nous pouvons reexecuter notre test unitaire 
pour constater qu'il fonctionne toujours parfaitement. 



Implementation par defaut pour les interfaces 

Certaines interfaces sont implementees de maniere strictement identique d'une classe a 
une autre. Cela aboutit a une duplication de code nuisible a la maintenabilite du logiciel. 

Grace a la POA, il est possible de creer une implementation par defaut pour une interface, 
automatiquement utilisee par les classes qui l'implementent. Ainsi, les classes implemen- 
tant l'interface ne sont pas dans l'obligation de fournir une implementation explicite. 

La solution consiste a creer un aspect interne a l'interface definissant 1' implementation 
de tout ou partie de ses methodes. Si seule une partie des methodes est definie, les classes 
implementant l'interface devront fournir une implementation explicite pour les autres. 

Cette technique peut etre utile pour transformer une classe abstraite en interface. 
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La figure 7.5 illustre le principe de fonctionnement de cette technique. 



Code originel 



public interface Unelnterface { 

void methode(); 
} 

public class UneClasse 1 
implements Unelnterface { 



public void methode () { 



//. 



} 



y 



} 



public class UneClasse 2 
implements Unelnterface { 

public void methode () { 

// idem code UneClasse 1 
} 



} 



Figure 7.5 

Implementation par defaut d'une interface 



Code refondu 



public interface Unelnterface { 
void methode (); 

static aspect Impl { 
public void Unelnterface .methode { 

^ AH- 
) 
} 
} 

public class UneClasse 1 implements 
Unelnterface { 

} 

public class UneClasse 2 implements 
Unelnterface { 

II... 
} 



Gains attendus et risques a gerer 

Grace a cette technique, la duplication de code peut etre supprimee au profit de 1' imple- 
mentation par defaut realisee sous forme d' aspect. Les actions correctives sur cette 
implementation sont de la sorte centralisees au sein d'une entite unique, evitant d'avoir a 
modifier plusieurs classes differentes. 

Les risques lies a 1' utilisation de cette technique sont faibles, car elle est peu intrusive 
vis-a-vis du logiciel dans son ensemble. Seules les classes ne fournissant pas d'imple- 
mentation utilisent automatiquement 1' implementation par defaut. Sur du code existant, 
toutes les classes qui implementent 1' interface fournissent necessairement une imple- 
mentation explicite. Nous pouvons done remplacer progressivement et de maniere tres 
controlee, lorsque cela s'applique, les implementations explicites par 1' implementation 
par defaut. Par ailleurs, cette technique n'impactant que le fonctionnement interne des 
classes, le perimetre des tests de non-regression est bien delimite. 
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Moyens de detection des cas d'application 

La recherche de duplication de code est la methode la plus efficace pour detecter les cas 
d'application de cette technique. II suffit de recouper les dupliquas avec les implementations 
des interfaces par les classes. 

Modalites d'application et tests associes 

A partir des dupliquas, nous pouvons deduire le code de 1' implementation par defaut a 
fournir a 1' interface. Une fois celui-ci defini, il faut creer au sein de 1' interface un aspect 
interne centralisant le code de chaque methode. 

Apres avoir defini l'aspect fournissant 1' implementation par defaut, nous pouvons refondre 
le code existant. Afin de securiser au maximum l'operation, il est conseille de proceder 
de maniere progressive, classe par classe. Dans la mesure du possible, il est preferable 
d'utiliser 1' implementation par defaut sur des evolutions afin de la mettre a l'epreuve du 
feu avant de generaliser son utilisation a l'existant. 

Avant de refondre le code existant, il est necessaire de definir un jeu de tests pour chaque 
classe refondue. L' utilisation de cette technique ayant uniquement des impacts sur le 
fonctionnement interne de la classe cible, nous pouvons limiter nos tests a son perimetre. 

La refonte du code existant est tres simple : il suffit de supprimer les implementations 
explicites correspondant a 1' implementation par defaut dans les classes du logiciel. 

Chaque suppression d' implementation explicite doit etre accompagnee de l'utilisation du 
jeu de tests pour detecter d'eventuelles regressions. 

Exemple de mise en ceuvre 

Supposons que nous ayons defini une interface specifiant le protocole pour transformer le 
contenu d'un objet en XML et creer ainsi qu' initialiser un objet a partir d'un flux XML. 

Cette interface, appelee SupportXML, se presente de la maniere suivante : 

package fr.eyrol les .exemples.poa.defautimpl ; 
import java.io. InputStream; 

interface SupportXML { 

publ ic String toXML( ) ; 

public Object fromXMKString pXML); 
} 

La methode toXML doit transformer le contenu d'un objet qui l'implemente, c'est-a-dire la 
valeur de ses attributs, en du XML stocke dans une chaine de caracteres. La methode 
fromXML realise l'operation inverse : elle cree un nouvel objet a partir d'un flux XML 
stocke dans une chaine de caracteres. 

LAPI standard J2SE fournit un ensemble de classes et de methodes permettant de realiser 
ces deux operations facilement pour les JavaBeans. II est done interessant de fournir une 
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implementation par defaut reposant sur les fonctionnalites de l'API standard afin d'en 
faire profiter automatiquement les JavaBeans du logiciel. 

L' implementation par defaut se presente sous la forme d'un aspect interne a l'interface, 
reposant sur le mecanisme d' introduction offert par AspectJ. Cet aspect, appele Impl , est 
reproduit ci-dessous : 

package f r.eyrol les.exemples.poa.defautimpl ; 

import Java. beans. XMLEncoder; 
import Java. beans. XMLDecoder; 
import java.io.ByteArraylnputStream; 
import java.io.ByteArrayOutputStream; 

interface SupportXML ( 

publ ic String toXMLt ) ; 

public Object fromXML(String pXML); 

static aspect Impl { 

public String SupportXML. toXML( ) { 

ByteArrayOutputStream out = new ByteArrayOutputStream( ) ; 
XMLEncoder encoder = new XMLEncoder(out) ; 
encode r.writeObjectt this) ; 
encoder. fl ush( ) ; 
encoder. close( ) ; 
return out.toString( ) ; 
} 

public Object SupportXML. fromXML( String pXML) { 
ByteArraylnputStream input = 

new ByteArrayInputStream(pXML.getBytes( ) ) ; 
XMLDecoder decoder = new XMLDecoder(input) ; 
Object o = decoder. readObjectt ) ; 
if (o.getClass()!=this.getClass()) { 

StringBuffer msg - new StringBuffert ) ; 
msg. append (o.getCl as s( ) ) ; 
msg.appendt" different de "); 
msg. append (t hi s.getCl ass ( ) ) ; 
throw new ClassCastException(msg.toString( ) ) ; 
} else { 

return o; 



) 

L' implementation par defaut de l'interface SupportXML repose sur les classes 
Java. beans. XMLDecoder et Java. beans. XMLEncoder. Cette implementation est definie d'une 
maniere tres proche de celle qui serait faite au sein d'une classe. La seule difference est 
qu'il faut prefixer le nom de la mefhode par le nom de l'interface (en gras dans le code). 
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Une fois definie notre implementation par defaut, nous pouvons la tester avec la classe 
suivante, qui implemente SupportXML sans fournir une implementation explicite : 

package fr.eyrol les .exemples.poa.defautimpl ; 

public class UneClasse implements SupportXML { 

private int unChamp; 
private String unAutreChamp; 

public String getUnAutreChampt ) { 
return unAutreChamp; 
} 

public void setUnAutreChamp(String unAutreChamp) { 

this. unAutreChamp = unAutreChamp; 
} 
public int getUnChampO { 

return unChamp; 
} 

public void setUnChampd'nt unChamp) ( 
this. unChamp - unChamp; 
} 

public static void main(String[] args) { 

UneClasse cl = new UneClasseO; 

cl.setUnChamp(lO); 

cl.setUnAutreChamp( "une valeur" ) ; 

System. out. println(cl.toXML( ) ) ; 

System, out. printl n( " "); 

UneClasse c2 = (UneClasse)cl.f romXML(cl.toXML( ) ) ; 

System. out. printl n(c2.toXML( ) ) ; 
} 
} 

Nous constatons que cette classe, qui ne fournit aucune implementation de SupportXML, ne 
genere pas d'erreur de compilation. AspectJ a introduit automatiquement et de maniere 
transparente 1' implementation par defaut au moment du tissage. 

Nous pouvons visualiser cette introduction grace a la vue des references croisees illustree 
a la figure 7.6. II suffit de cliquer sur le nom de la methode (toXML ou fromXML) dans 
P aspect interne pour rafraichir la vue avec les informations qui nous interessent. 



> B%~ 



6 <* dedared on 
I <1 iwpportXML 
; @ > UneClasse 



Figure 7.6 

Introduction de V implementation par defaut 
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Si nous executons cette classe (elle possede une methode main), nous obtenons le resultat 
suivant : 



<?xml version="1.0" encoding="UTF-8"?> 
<java version="1.4.1_02" cl ass="java. beans. XMLDecoder"> 
<object class="f r.eyrol les .exemples.poa.defautimpl . UneCl asse"> 
<void property="unAutreChamp"> 
<string>une valeur</string> 
</void> 

<void property="unChamp"> 
<int>10</int> 
</void> 
</object> 
</java> 



<?xml version="1.0" encoding="UTF-8"?> 
<java version="1.4.1_02" cl ass="java. beans. XMLDecoder"> 
<object class="f r.eyrol les . exempl es.poa.defautimpl . UneCl asse"> 
<void property="unAutreChamp"> 
<string>une valeur</string> 
</void> 

<void property="unChamp"> 
<int>10</int> 
</void> 
</object> 
</java> 



Nous pouvons constater que 1' implementation par defaut a parfaitement fonctionne puisque 
nous avons pu creer c2, copie de cl, a partir du flux XML de cl. 

Gestion des exceptions 

La gestion des exceptions au sein d'une classe, voire d'un logiciel, est souvent repetitive 
d'une methode a une autre. En cas de modification de cette gestion, les couts sont gene- 
ralement importants, car un tres grand nombre de classes sont directement impactees. Par 
ailleurs, la gestion des exceptions peut nuire a la lisibilite du code et alourdir les methodes 
par de nombreux blocs try/catch. 

La POA fournit les elements necessaires pour centraliser une gestion d'exceptions au sein 
d'un aspect. Cela permet d'alleger le code des methodes de maniere souvent significative 
en supprimant les blocs try/catch. 
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II existe de multiples possibilites pour gerer les exceptions grace a la POA. La solution 
que nous presentons ici comporte deux etapes : 

1. Transformer l'exception a gerer en une exception d'execution, c'est-a-dire derivant la 
classe j a va.lang. Run time Except ion. Les blocs try/catch ne sont done plus necessaires. 

2. Definir un code advice de type around contenant le bloc try/catch necessaire a 
1' interception de l'exception associe a une coupe sur les methodes susceptibles de 
la generer. 

La figure 7.7 illustre le principe de fonctionnement de cette technique. 



Code originel 



Code refondu 



public class UneClasse { 

public void methodeA() 
throws UneException { 



//.. 



} 



public void methodeB () { 
try { 

methodeAQ; 

} 

catch ( UneException e) { 



//. 



^. 



} 



} 



public void methodeC () { 
try { 
methodeA(); 

} 

catch ( UneException e) { 
// Idem code methodeB 
} 
} 



} 




public aspect Extraction { 
private pointcut catchExc () 

declare soft : 
UneException : catchExc() 



Object around () : catchExc() { 
try { 
return proceed (); 

} 

catch (UneException e) { 

} 

return null ; 
} 



public class UneClasse { 

public void methodeAQ 
throws UneException { 



//.. 



} 



public void methodeB() { 
methodeA (); 




pc£>lic void methodeC() { 
methodeA (); 



} 



} 



Figure 7.7 

Gestion des exceptions 



Gains attendus et risques a gerer 

Les principaux gains attendus par 1' utilisation de cette technique sont de supprimer le 
code de gestion des exceptions dans les methodes, allegeant d'autant leur contenu, et de 
centraliser cette gestion au sein d'un aspect afin de faciliter sa maintenance. 
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Les risques sont proportionnels a la portee de 1' aspect. Si celui-ci a une portee limitee a 
quelques classes, voire une seule si la gestion est partagee par plusieurs methodes, le 
perimetre de test reste gerable. Par contre, s'il s'agit d'un aspect couvrant tout le logiciel, 
la charge de test de non-regression est considerable. II est done preferable d'utiliser cette 
technique de maniere chirurgicale ou progressive en limitant la portee de la coupe la ou 
les gains ne sont pas annules par les risques encourus. 

AspectJ ne permet pas encore d'avoir acces aux variables locales d'une methode inter- 
ceptee. Cela limite fortement l'utilisation de cette technique, notamment pour la gestion 
des exceptions liees a JDBC, pour laquelle le traitement classique consiste a fermer les 
ressources JDBC allouees a la methode sous forme de variables locales. 

Moyens de detection des cas d'application 

La recherche de duplication de code est le meilleur detecteur de cas d'application. 
Malheureusement, la gestion des exceptions ne comporte souvent que quelques lignes. 
Cela oblige a regler l'outil de maniere qu'il detecte des dupliquas de trois ou quatre 
lignes generant un grand nombre de fausses alertes. 

Modalites d'application et tests associes 

La detection des dupliquas permet de trouver le contenu de la gestion des exceptions 
ainsi que sa portee. Nous pouvons definir quelles sont les exceptions a transformer, quel 
est le contenu de la gestion et quelles sont les classes concernees par la coupe et creer un 
aspect a partir de ces informations. 

Pour eviter une charge de test trap importante, il est recommande de deployer 1' aspect 
sur un nombre limite de classes. Pour chacune d'elles, il est necessaire de definir un jeu 
de tests. 

Une fois 1' aspect cree et les jeux de tests definis, nous pouvons supprimer dans le code des 
methodes la gestion des exceptions. Quand la suppression est terminee, nous pouvons 
rejouer les tests afin de detecter d'eventuelles regressions. 

Exemple de mise en ceuvre 

Supposons que notre logiciel necessite un certain nombre de parametres pour fonction- 
ner. Idealement, ces parametres doivent etre externalises dans des fichiers de configura- 
tion. J2SE fournit une classe standard pour lire ces fichiers de configuration : 
Java . uti 1 . ResourceBundle. 

La classe suivante utilise une instance de ResourceBundl e pour lire un fichier de configura- 
tion (fichier configuration.properties a mettre dans le CLASSPATH) contenant norma- 
lement deux parametres, la version du logiciel et le nombre d'utilisateurs maximal 
pouvant l'utiliser. Si le fichier est absent ou qu'un des parametres soit inexistant, une 
exception d'execution de type Java . uti 1 . Mi ssi ngResourceException est generee. Des valeurs 
par defaut sont alors utilisees a la place. 
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Le code de la classe Configuration est le suivant : 

package fr.eyrol les . exemples.poa. except ions; 

import java.util .ResourceBundle; 

import java.util .MissingResourceException; 

public class Configuration { 

private ResourceBundle config; 

public static final String VERSION_DEFAUT = "Non precisee" 
public static final int UTILMAX_DEFAUT = 2; 

public Configuration; ) { 
try { 

config = ResourceBundle. getBundle( "configuration" ) ; 
} 

catch (MissingResourceException e) { 
config = null ; 



public String getVersionO { 
if (config==nul 1 ) { 

return Configuration.VERSION_DEFAUT; 
} 
try { 

return config.getSt ring ("vers ion") ; 
} 
catch(MissingResourceException e) { 

return Configuration.VERSION_DEFAUT; 
} 
) 

public int getUtil isateursMaxt ) { 
if (config==nul 1 ) { 

return Configuration.UTILMAX_DEFAUT; 
} 
try { 

return Integer. parselnt( 
config.getStringt "util isateursMax" ) ) ; 
} 
catch(MissingResourceException e) { 

return Configuration.UTILMAX_DEFAUT; 
} 
) 



Nous constatons que la gestion des exceptions, piece centrale du mecanisme de valeurs 
par defaut, est similaire pour les methodes getVersion et getUtil isateursMax. II est done 
interessant de rendre ce mecanisme plus modulaire en utilisant un aspect le prenant en 
charge directement. 
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Avant d'utiliser la POA pour modulariser la gestion des exceptions, nous pouvons definir 
un test unitaire avec JUnit arm de tester le cas oil le fichier de configuration est absent 
(evenement declencheur du mecanisme des valeurs par defaut) : 

package f r.eyrol les.exemples.poa. exceptions; 

import junit.framework.TestCase; 

public class ConfigurationTest extends TestCase { 

private Configuration config; 

protected void setUpO throws Exception { 
config = new Configuration( ) ; 
} 

public void testGetVersiont ) { 
assertEquals(Configuration.VERSION_DEFAUT,config.getVersion( ) ) ; 
} 

public void testGetlltil isateursMaxt ) ( 
assertEquals(Configuration.UTILMAX_DEFAUT, 
config.getUtil isateursMax( )) ; 



L' aspect de gestion des valeurs par defaut peut etre soit un aspect interne, si l'utilisation 
de ResourceBundl e est limitee a la classe Configuration, soit un aspect general du logiciel, 
si plusieurs classes sont concernees. Ici, nous considerons qu'il s'agit d'un aspect general, 
bien qu'il pourrait etre tout aussi bien un aspect interne. 

Cet aspect comporte deux coupes, la premiere pour intercepter les exceptions emises par 
la methode getBundle signalant l'absence du fichier de configuration et la seconde pour 
intercepter les exceptions generees par la methode getString signalant l'absence d'une 
propriete dans le fichier. 

Chaque coupe est associee a un code advice de type around afin de placer un bloc try/ 
catch autour de l'appel aux deux methodes enoncees ci-dessus. II s'agit de reproduire 
dans ces codes advice le mecanisme extrait du code originel. 

Notre aspect GestionDesExceptions se presente de la maniere suivante : 

package f r.eyrol les.exemples.poa. exceptions; 

import java.util . ResourceBundl e; 

import java.util .MissingResourceException; 

aspect GestionDesExceptions ( 

private boolean configAbsente = false; <— Q 

public static final String VERSION_DEFAUT - "Non precisee"; <— Q 
public static final String UTILMAX_DEFAUT = "2"; 

private pointcut catchGetBundle( ) : <— © 
cal 1 ( ResourceBundl e ResourceBundl e. getBundle (St ring) ) ; 



Techniques avancees de refactoring 

Partie II 

private pointcut catchGetStringtString propriete) : <— © 
call (String ResourceBundle.getSt ring (St ring) )&&args( propriete) ; 

private String getValeurParDefauttString pPropriete) { <— © 
if ("util isateursMax" .equal s(pPropriete) ) { 

return GestionDesExceptions.UTILMAX_DEFAUT; 
} else if ( "version" .equals(pPropriete) ) { 

return GestionDesExceptions.VERSION_DEFAUT; 
} 

return nul 1 ; 
} 

Object aroundO : catchGetBundle( ) { <— © 
try { 

return proceed( ) ; 
} 
catch(MissingResourceException e) { 

configAbsente = true; 
} 

return null ; 
} 

String around(String propriete) : catchGetString(propriete) { <— © 
if (configAbsente) { 

return getVa 1 eur Pa rDef a ut( propriete) ; 
} 
try { 

return proceed( ) ; 
} 
catch(MissingResourceException e) { 

return getVa 1 eur Pa rDef a ut( propriete) ; 
} 
} 
} 

L' aspect GestionDesExceptions comporte trois attributs : 

• conf i gAbsent (repere ©) est un booleen utilise pour savoir s'il faut renvoyer une valeur 
par defaut suite a 1' absence du fichier de configuration. 

• VERSION_DEFAUT et UTI LMAX_DEFAUT (repere ©) sont des extractions du code originel. Leur 
presence dans Conf i gurati on n'est plus justifiee du fait de la modularisation de la meca- 
nique des valeurs par defaut dans 1' aspect. 

Deux coupes sont definies (reperes ©) pour capturer respectivement les appels a Resour- 
ceBundle.getBundle et ResourceBundl e.getString. Cette derniere isole 1' argument passe en 
parametre a getString (via le mot-cle args) afin de l'utiliser dans le code advice pour 
selectionner la valeur par defaut correspondant a celui-ci. 
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Une methode privee, getVal eurParDef aut (repere ©), centralise la mecanique de selection 
de la valeur par defaut en fonction du nom de la propriete passee en parametre. 

Pour terminer, deux codes advice sont definis. Le premier (repere ©), lie a la coupe 
catchGetBundle, positionne, en cas d'absence du fichier de configuration, l'attribut 
configAbsente a vrai afin d'enclencher la mecanique de valeur par defaut. Le second 
(repere Q), lie a la coupe catchGetString, enclenche la mecanique si le fichier de configu- 
ration est absent ou si la propriete est introuvable dans celui-ci. 

Nous n'avons pas besoin de declarer MissingResourceException comme etant une excep- 
tion d'execution, car tel est deja le cas. Dans le cas contraire, nous aurions du utiliser le 
code advice declare soft. 

Nous pouvons maintenant supprimer dans le code originel les traitements modularises 
dans l'aspect : 

package f r.eyrol les.exemples.poa. exceptions; 

import java.util . ResourceBundle; 

public class Configuration { 

private ResourceBundle config; 

public Configuration( ) { 
config = ResourceBundle. getBundle( "configuration") ; 
} 

public String getVersionO { 
return config.getSt ring ("vers ion") ; 
} 

public int getUtil isateursMax( ) { 
return Integer.parseInt(config.getString("util isateursMax" ) ) ; 
} 

} 

Notons que Configuration devient quasiment inutile et que ResourceBundle pourrait etre 
utilisee directement. 

Pour achever 1' operation, il est necessaire de la verifier avec le test unitaire mis au point 
precedemment. Les constantes ayant ete extraites de la classe Configuration et le type de 
l'une d'elles ayant ete modifie (de int a Stri ng), nous devons legerement modifier le code 
du test en consequence (en gras dans le code ci-dessous) : 

package f r.eyrol les.exemples.poa. exceptions; 

import j unit .framework. TestCase; 

public class ConfigurationTest extends TestCase { 

private Configuration config; 

protected void setUpO throws Exception { 
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config = new Configuration( ) ; 
} 

public void testGetVersion( ) { 
assert Equal s(GestionDesExceptions. VERS ION_DEFAUT 

, config. getVersion( ) ) ; 
} 

public void testGetUtilisateursMax( ) { 
assertEqualsdnteger 

.parseInt(GestionDesExceptions.UTILMAX_DEFAUT) 
, config. getUtil isateursMax( ) ) ; 
} 
} 

Si nous executons ce test, nous constatons que notre nouvelle gestion des exceptions 
fonctionne conformement a nos attentes. 



Gestion des variantes 

Un logiciel donne peut avoir plusieurs variantes, necessitant d' avoir au sein de l'outil de 
gestion de configuration plusieurs branches pour en tenir compte. Si ces variantes sont 
tres ciblees et ne concernent que le comportement de certaines methodes, ce mode de 
gestion peut s'averer couteux. 

La solution consiste a choisir la base du logiciel et a realiser des variantes de cette base 
grace a des aspects. Chaque aspect contiendra les modifications a apporter au comporte- 
ment des methodes afin de creer une variante. Cela consiste essentiellement en des codes 
advice de type around associes a des coupes interceptant les methodes dont le comporte- 
ment doit etre modifie. Si un acces aux methodes (ou attributs) privees ou protegees est 
necessaire, il faut utiliser un aspect privilegie. 

La figure 7.8 illustre le principe de fonctionnement de cette technique. 

Gains attendus et risques a gerer 

Le principal gain est de n'avoir plus de branche au sein de l'outil de gestion de configu- 
ration, avec n versions differentes d'une meme classe pour tenir compte des variantes. 
Une branche unique suffit, et les variantes sont centralisees au sein d' aspects, generale - 
ment un par variante, plus facilement gerables qu'une multitude de classes. 

Les risques a gerer pour la mise en place de cette technique sont proportionnels a la 
complexite de chaque variante. Cette technique est bien adaptee pour des variantes 
mineures n'affectant le comportement que de quelques methodes facilement testables. 

Moyens de detection des cas d'application 

Seule une revue de code des variantes permet d'identifier s'il s'agit de cas d'application. 
Les variantes impliquant un grand nombre de classes doivent etre evitees. 
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Code originel 



Code refondu 



public class UneClasse 


{ 


public void methodeA 


I 


//... 




} 




} 




public class UneAutreClasse { 


public void methodeB 


I 


//... 




} 




} 





/ 



public class UneClasse { 
public void methodeA () { 
// autre implementation Y 



-y 



/ 



/ 



public class UneAutreClasse { 
public void methodeB () { 
II autre implementation / 

} 



/ 



/ 



/ 



public aspect Variante { 
private pointcut varianteA () : 

private pointcut varianteB () ^ 

v oid around () : varianteAQ { 

A "- 



v oid around () : varianteB () { 



4 



1 



II.. 



public class UneClasse { 
public void methodeA () { 

//... 
} 
} 

public class UneAutreClasse { 
public void methodeB () { 

//... 
} 
} 



Figure 7.8 

Gestion des variantes 



Modalites d'application et tests associes 

La premiere etape consiste a definir la base du logiciel et le contenu de chaque variante. 
Cette etape peut s'averer complexe. Si tel est le cas, nous vous conseillons d'abandonner 
l'utilisation de cette technique. 

Une fois la base et ses variantes bien definies, un aspect est cree pour chaque variante, qui 
centralise l'ensemble des modifications correspondantes a apporter a la base. Bien 
entendu, ces modifications doivent etre exprimables sous forme de codes advice ou 
d' introductions. Si tel n'est pas le cas, la technique n'est pas utilisable. 

Des jeux de tests doivent etre mis au point pour chaque variante. Quand l'operation de 
refactoring est achevee, nous pouvons supprimer les classes modifiees par chaque 
variante et activer 1' aspect qui les remplace. Afin de faciliter les tests de non-regression, 
nous recommandons de proceder variante par variante. 



Exemple de mise en oeuvre 

Supposons que nous ayons developpe une boite a outils financiere contenant differentes 
implementations de formules classiques utilisees en banque/assurances au sein d'une 
classe Java unique (BoiteAOutilsFin). Cette boite a outils dispose de deux variantes : une 
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variante de demonstration, avec des possibilites limitees, et une variante de production, 
avec toutes les fonctionnalites activees. 

Sans la POA, nous devons soit gerer deux versions differentes de BoitesAOutilsFin, soit 
gerer dans un code unique les deux situations, alourdissant inutilement le code de la 
variante de production par des tests pour selectionner la variante a executer. 

L'idee est done d'implementer la variante de demonstration sous la forme d'un aspect 
modifiant le comportement de la variante de production. 

Le code de la variante de production est reproduit ci-dessous : 

package fr.eyrol les . exemples.poa. van' ante; 
public class BoiteAOutil sFin { 

private double recupereCours 

(String monnaieOrig, String monnaieConv) { 

// Valeur bouchon 

return 1.3081; 
} 



public double convertitMonnaie 
(double montant, String monnaieOrig, String monnaieConv) 
doubl e cours=recupereCours( monnaieOrig, monnaieConv) ; 



^O 



// Recuperation du cours de la monnaie de conversion exprimee 

// dans la monnaie d'origine 

// ... 

return montant*cours; 



public double cal culePlacementATerme 
(double montant, int duree, double taux) { <— Q 
return montant*Math.pow(l+taux, duree) ; 
} 

public static void main(String[] args) { <— © 

BoiteAOutilsFin b = new BoiteAOutilsFinf ) ; 

System. out. println(b. convertitMonnaie (100, "EUR" ."USD") ) ; 

Sys tern. out. printl n(b.cal culelnterets Placement (100, 2, 0.05) 
} 



1 



La methode convertitMonnaie (repere Q) convertit une somme exprimee dans une 
monnaie donnee en une autre monnaie. Pour cela, elle utilise la methode privee recupere- 
Cours, qui recupere le cours de la monnaie de conversion exprime en monnaie d'origine. 

La methode cal culePlacementATerme determine la valeur d'une somme bloquee pendant 
une certaine duree et remuneree a un taux d'interet fixe a l'avance. 

La methode main est utilisee pour tester le fonctionnement de la boite a outils. Si nous 
l'executons, nous obtenons le resultat suivant : 
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La variante consiste a limiter l'utilisation de converti tMonnaie (conversion de l'euro vers 
le dollar uniquement) et de calculePlacementATerme (montant inferieur a 10 000, duree 
inferieure a 20 et taux inferieur ou egal a 5 %). 

Cette variante s'implemente tres simplement sous forme d'aspect. II s'agit de definir une 
coupe (reperes © et © ci-dessous) et un code advice de type before pour traiter les appels 
a chacune des deux methodes et de verifier si les parametres qui leur sont passes respec- 
tent bien les conditions que nous venons d'enoncer. Si tel n'est pas le cas, une exception 
d' execution est generee (reperes et © ci-dessous). 

L' aspect VarianteDemo se presente sous la forme suivante (il s'agit d'un aspect general 
pour permettre d'inclure d'autres classes dans la variante, si necessaire) : 

package f r.eyrol les.exemples.poa. variante; 

aspect VarianteDemo { 

private pointcut convertisseurt ) : 
cal 1 (double BoiteAOutil s Fin. converti tMonnaie 

(doubl e, String, String) ) ; <— © 

private pointcut calculateurPlacement( ) : 
cal 1 (doubl e Boi teAOuti 1 sFi n . cal cul ePl acementATerme 

(double, int, double) ) ; <— © 

private void genereException(String fonction) { 

StringBuffer msg = new StringBuffer("\nUtilisation de\n"); 

msg. append (fonction) ; 

msg.appendt "\nnon disponible dans la version de demo.\n"); 

throw new RuntimeException(msg.toString( ) ) ; 
} 

before(double montant, String monnaieOrig, String monnaieConv) : 
convertisseurt ) && argstmontant , monnaieOrig, monnaieConv) { 
if ( ! "EUR" .equal s(monnaieOrig) | | ! "USD" .equal s(monnaieConv) ) { 
genereException(thisJoinPointStaticPart 

.getSignaturef ) .toStringt ) ) ; <— © 
} 
} 

before(double montant, int duree, double taux) : 
calculateurPlacement( ) && argstmontant, duree, taux) { 
if (!(montant<10000)| | !(duree<20)| | ! (taux<=0.05) ) { 
genereException(thisOoinPointStaticPart 

.getSignature( ) .toStringt ) ) ; <— © 
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L'objet thisJoinPointStaticPart (en gras dans le code ci-dessus) est un objet standard 
fourni aux codes advice par AspectJ. Nous l'utilisons pour recuperer le nom de la methode 
appelee via sa methode getSignature. 

Si nous reexecutons notre classe BoiteAOutilsFin apres application de l'aspect, nous 
obtenons le meme resultat que precedemment puisque les contraintes que nous avons 
definies pour la variante de demonstration sont respectees. 

Par contre, si nous la modifions de maniere a ne plus les respecter, nous obtenons une 
exception d' execution : 



Java . lang. Runtime Except ion: 

Utilisation de 

doubl e f r.eyrol les .exemples .poa .variante.BoiteAOutilsFin.cal culePlacementATerme 
^••(double, int, double) 

non disponible dans la version de demo. 

at 

f r.eyrol 1 es .exempl es.poa .variante.VarianteDemo.genereException(VarianteDemo.aj : 

15) 

at 

f r.eyrol les. exempl es.poa . variante. VarianteDemo. a jc$before$f r_eyrol les 

_exemples_poa_variante_VarianteDemo$2$61bd59b2(VarianteDemo.aj :26) 

at 

f r.eyrol 1 es .exempl es .poa . variante. BoiteAOuti Is Fin. main (Boi teAOutilsFin. Java: 27) 

Exception in thread "main" 



Optimisation des traitements 

Outre la modularisation des traitements, la POA permet d'introduire du code dans l'existant 
arin de l'enrichir et l'adapter plus facilement aux besoins. 

Dans le cadre d'un projet de refactoring, cette capacite de la POA permet d'ameliorer 
certains points critiques du logiciel en terme de performances, sans necessiter de toucher 
directement au code existant, ce qui est tres appreciable pour ce type de projet. 

Gestion de cache 

L' execution de certaines fonctions, comme les methodes renvoyant un resultat, peut etre 
extremement couteuse en terme de performance et penalisante pour l'utilisateur. Or 
celles-ci sont appelees frequemment. Si nous pouvons associer le resultat d'une fonction 
a ses parametres, nous pouvons mettre en place un cache. L'idee est de stacker en 
memoire les resultats afin de les resservir lorsqu'un nouvel appel de la fonction utilise les 
memes parametres. 
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La figure 7.9 illustre le principe de fonctionnement de cette technique. 

Code originel 



public class UneClasse { 

public Object methodeA (Object p) { 
// execution couteuse 

} 
} 



Code refondu 



public aspect Cache { 
private pointcut cache () 



Object around () : cache() { 

if (dansCache!=null) { 
return dansCache ; 

} else { 
return proceed (); 

} 



} 



} 



public class UneClasse { 

public Object methodeA (Object p) { 
// execution couteuse 

} 
} 



Figure 7.9 
Gestion de cache 



Gains attendus et risques a gerer 

Le principal gain de la mise en place d'un cache est 1' amelioration des performances en 
diminuant de maniere importante les appels a des fonctions couteuses. 

Les risques sont faibles et sont concentres essentiellement dans la mecanique du cache. 
Un cache mal gere peut en effet generer des fuites memoire et rendre le logiciel inutilisable. 

Moyens de detection des cas d'application 

Lutilisation d'un profiler est un excellent moyen de detection des fonctions susceptibles 
d'etre optimisees. Cependant, pour que les resultats fournis par le profiler soient justes, il 
est necessaire de simuler une utilisation du logiciel la plus proche possible de la realite. 

Modalites d'application et tests associes 

Cette technique demande au prealable la creation d'un aspect abstrait implementant la 
mecanique de cache independamment de toute methode. Elle consiste essentiellement a 
definir un code advice de type around. Ce code advice fera un appel reel ou non a la fonction 
cachee en fonction du contenu du cache. 
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Une fois cet aspect abstrait defini, nous creons des aspects concrets derivant de celui-ci 
pour chaque fonction a cacher. 

Avant d'activer les aspect de cache, il est necessaire de mettre au point des jeux de tests 
sur le code originel des fonctions cachees. Quand les aspects sont mis en place, nous les 
utilisons pour detecter d'eventuelles regressions introduites par l'operation de refactoring. 

Pour valider les gains de performance, il est necessaire d'utiliser a nouveau le profiler. 

Exemple de mise en ceuvre 

Reprenons notre exemple de boite a outils financiere. La methode recupereCours (simulee 
dans l'exemple) est generalement couteuse puisqu'il s'agit de recuperer un cours dans une 
base ou sur un reseau financier. II est done interessant de mettre en place un systeme de cache 
evifant des recuperations trop frequentes et ameliorant ainsi les performances du logiciel. 

Pour verifier le bon fonctionnement du cache, nous avons modifie legerement le code de 
BoiteAOutilsFin afin de realiser deux appels identiques pour sollicker le cache et d'affi- 
cher un message lorsque la methode est executee (modifications en gras dans le code) : 

package fr.eyrol les . exemples.poa. van' ante; 

public class BoiteAOutilsFin { 

private double recupereCours 
(String monnaieOrig, String monnaieConv) { 

System. out. println( "Execution de recupereCours."); 

return 1.3081; 
} 

public static void main(String[] args) ( 
BoiteAOutilsFin b = new BoiteAOutil sFin( ) ; 

System. out. println(b.convertitMonnaie( 100, "EUR", "USD")) ; 
System. out. println(b.convertitMonnaie( 100, "EUR", "USD")) ; 

} 
} 

La gestion de cache etant un probleme particulierement generique, nous allons definir un 
aspect abstrait implementant les mecanismes generaux. II sera ensuite specialise pour 
prendre en compte specifiquement recupereCours. 

La gestion de cache donnee ici est volontairement simpliste afin de ne pas compliquer 
inutilement l'exemple. La problematique du rafraichissement du cache (importante pour 
avoir un cours a jour) n'est done pas traitee. 

L' implementation realisee fonctionne en utilisant une table de hachage. Cette table 
contient les resultats renvoyes par recupereCours et possede une cle representant les 
parametres ayant permis de les determiner. Afin de gerer cette cle, nous utilisons la classe 
org .apache . commons .coll ecti ons . key val ue . Mul ti Key, disponible dans la bibliotheque Jakarta 
Commons Collections (voir http://jakarta.apache.org/commons/collections/). 
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Une coupe est definie pour intercepter les appels, dont les resultats doivent etre caches, 
en l'occurrence recupereCours. La coupe est associee a un code advice de type around 
gerant le cache. La mise en cache est declenchee lorsqu'un appel intercepte par la coupe 
utilise des parametres ne correspondant a aucune cle dans la table de hachage. Si la cle 
existe dans la table de hachage, la valeur stockee dans la table est renvoyee directement. 

Laspect abstrait Cache est implemente de la maniere suivante : 

package f r.eyrol les.exemples.poa. cache; 

import java.util .Map; 

import java.util .Hashtable; 

import org. apache. commons. col lect ions. key val ue.MultiKey; 

abstract aspect Cache { 

private Map cache = new HashtableO; 

protected abstract pointcut methodeCachee( ) ; <— Q 

Object aroundO : methodeCachee( ) { 
Object enCache = recupereDansCache(thisJoinPoint.getArgs( ) ) ; <— Q 
if (enCache==null ) { 
enCache = proceedt ) ; 

miseEnCache(thisJoinPoint.getArgs( ), enCache); <— © 
} 

return enCache; 
} 

private void miseEnCache(Object[] pCle, Object pValeur) { 
cache. put (new Mul tiKey(pCle) , pValeur) ; 
} 

private Object recupereDansCache(Object[] pCle) { 
return cache. gettnew Mul tiKey(pCle) ) ; 
} 
} 

La coupe methodeCachee (repere Q) est declaree comme etant abstraite, car c'est elle qui 
est specifique de chaque cas d' utilisation. Elle est done definie par specialisation. La 
mecanique du cache est prise en charge par l'unique code advice de l'aspect et repose sur 
deux methodes, miseEnCache et recupereDansCache, qui accedent a la table de hachage 
apres avoir cree la cle a partir des valeurs passees en parametres a la methode interceptee 
par la coupe. Ces valeurs sont recuperees sous forme de tableau d'objets par la methode 
getArgs de l'objet standard AspectJ thisJoinPoint (reperes Q et 0). 

La mecanique generique de cache etant en place, nous pouvons la specialiser pour cacher 
les resultats produits par recupereCours : 

package f r.eyrol les.exemples.poa. cache; 

aspect CacheCours extends Cache { <— Q 
protected pointcut methodeCachee( ) : 
cal 1 (double BoiteAOutilsFin. recupereCours (St ring, St ring) ) ; <— Q 
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Cette specialisation (repere Q) consiste uniquement a definir la coupe methodeCachee 
(repere ©). En l'occurrence, celle-ci intercepte les appels a recupereCours. 

Si nous executons le code de Boi teAOuti 1 s, nous obtenons le resultat suivant : 



Exe 


:ution 


de 


recupereCours. 


130 


81 






130 


81 







Nous constatons que le message signalant l'execution de la methode recupereCours n'est 
affiche qu'une seule fois et que les deux memes resultats ont ete produits. Notre cache a 
parfaitement fonctionne. 



Remplacement de methode 

Ce probleme s'enonce tres simplement : une methode existante, tres utilisee au sein du 
logiciel, doit etre remplacee par une autre. 

La POA permet de modifier radicalement le comportement d'une methode grace au code 
advice around. La solution consiste a utiliser ce type de code advice pour remplacer un 
appel a une methode par un appel a une autre methode. Cela peut s'averer utile pour 
realiser des simulacres d'objets dans le cadre de tests unitaires. 

La figure 7.10 illustre le principe de fonctionnement de cette technique. 

Code originel 



public class UneClasse { 
public void methodeRemplacee () { 



// 



} 



Code refondu 



public aspect Remplacement { 
private pointcut remplace () 

void around () : remplace () { 

// Code de remplacement 
} 
} 



public class UneClasse { 

public void methodeRemplacee () { 
// Ce code ne s 'execute plus 

} 
} 



Figure 7.10 

Remplacement de methode 
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Gains attendus et risques a gerer 

Le principal gain de cette technique est de generaliser le remplacement des appels par une 
simple recompilation, la ou les techniques habituelles obligent a modifier le code manuel- 
lement ou au moyen de moulinettes dont l'utilisation s'avere plus ou moins hasardeuse. 
Avec cette technique, nous pouvons lisser dans le temps la modification reelle du code. 

Le principal risque est d'introduire des regressions avec le remplacant. II est done vive- 
ment recommande de reserver cette technique a des appels parfaitement maitrises et peu 
susceptibles de generer des effets de bord. 

Moyens de detection des cas d'application 

La detection des appels de methodes a remplacer est difficile, car cette problematique 
depend fortement du logiciel. Hormis des cas triviaux, seule une revue de conception et 
de code approfondie permet de detecter d'eventuels candidats. 

Modalites d'application et tests associes 

Pour tout appel a remplacer, il est necessaire de definir le remplacant. Celui-ci se doit de 
fonctionner en respectant au minimum le contrat de la methode dont 1' appel est remplace 
(valeur de retour, parametres, etc.). 

Une fois le remplacant determine, nous creons un aspect contenant une coupe interceptant 
tout ou partie des appels a remplacer. Cette coupe est associee a un code advice de type 
around contenant soit 1' appel a la methode remplacante, soit directement le code a executer. 

Avant d'activer 1' aspect, il est necessaire de definir un jeu de tests pour detecter d'even- 
tuelles regressions. Si le remplacement concerne l'ensemble du logiciel et impacte un 
grand nombre de classes, la tache peut s'averer ardue. C'est la raison pour laquelle cette 
technique doit etre utilisee soit sur un perimetre tres limite, soit sur un appel a une 
methode simple, bien maitrisee et avec un faible risque d' effets de bord. 

Exemple de mise en ceuvre 

II est frequent dans les logiciels de trouver des appels a System. out. println pour afficher 
des traces applicatives. C'est une solution simple, mais qui peut s'averer couteuse en 
performance, l'affichage sur la console n'etant pas des plus veloces. Par ailleurs, il n'est 
pas possible de les desactiver. 

La classe suivante effectue ce genre d' appel, que nous aimerions remplacer par un veritable 
outil de log, celui fourni en standard par J2SE, par exemple, depuis la version 1.4 : 

package f r.ey roll es.exemples.poa. remplace; 

public class UneClasse { 

public void uneMethodeC) { 
System. out. println( "LOG : entree uneMethode") ; 

System. out. println( "LOG : debut traitement x"); 
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II ... 

System. out .printlnC'LOG : fin traitement x"); 

System. out. printlnC'LOG : sortie uneMethode"); 
} 

public static void main(String[] args) ( 

UneClasse c - new UneClasseO; 

c.uneMethodet ) ; 
} 
} 

Si nous executons cette classe, nous obtenons l'affichage suivant 



LOG 


entree uneMethode 


LOG 


debut traitement x 


LOG 


fin traitement x 


LOG 


sortie uneMethode 



Le principe de 1' aspect de remplacement d'appels consiste a definir une coupe interceptant 
tous les appels incrimines et a les associer a un code advice around contenant le code 
de remplacement : 

package fr.eyrol les .exemples.poa.remplace; 

import java.util .logging. Logger; 
import java.util .logging. Level ; 

aspect Traces { 

private static Logger logger = Logger. getLoggerC") ; <— © 

private pointcut trace(Object msg) : <— © 
calKvoid java.io.PrintStream.println(*) ) && 
args(msg) && 
within(f r.eyrolles.exemples.poa. remplace.*) ; 

void around(String msg) : trace(msg) { <— © 
String nomClasse = 

thisJoinPoint. getThi s C ) .getClass( ) .getName( ) ; 
String methode = 

this End osingJoinPointStaticPart.getSignature( ) .toString( ) ; 
methode = methode. replaceFirst(nomClasse+" .","") ; 
logger. logp( Level . I NFO, nomClasse, methode, msg. toString( ) ) ; 
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Notre aspect repose sur l'API Java Logging de J2SE, dont la classe centrale est 
java . uti 1 . Logger, puisque c'est a partir d'elle que les traces sont parametrees et affichees. 
Dans notre exemple, l'utilisation de Logger est basique puisque nous utilisons l'instance 
par defaut (repere Q i. 

La coupe trace (repere©) intercepte les appels a la methode println de la classe 
java.io.PrintStream, dont System. out est une instance. Cette interception recupere 1' argu- 
ment unique de pri ntl n, car il constitue le message a afficher. Ce message (msg) est volon- 
tairement du type Object, pri ntl n possedant une variante pour chaque type Java. En une 
seule coupe, nous capturons de la sorte toutes les variantes (utilisation de * dans le point 
de jonction pour designer un parametre de type quelconque). Enrin, pour limiter la portee 
de notre aspect, nous avons defini comme contrainte que les appels a println se trouvent 
dans le package f r . ey rol 1 es . exempl es . poa . rempl ace. 

Le code advice around associe a la coupe trace implemente le nouveau comportement de 
println. II recupere dans un premier temps le nom de la classe et le nom de la methode 
ayant appele println. Ensuite, il utilise ces informations et le message capture par la 
coupe pour appeler la fonction de trace de la classe Logger. 

Maintenant que notre aspect est entierement defini, nous pouvons executer de nouveau 
notre exemple : 



8 fevr. 2005 09:58:06 fr.eyrol les. exempl es. poa. rempl ace. UneClasse void uneMethodeO 

INFO: LOG : entree uneMethode 

8 fevr. 2005 09:58:06 f r.ey rol les. exempl es. poa. remplace. UneClasse void uneMethodeO 

INFO: LOG : debut traitement x 

8 fevr. 2005 09:58:06 f r.ey rol les. exempl es. poa. remplace. UneClasse void uneMethodeO 

INFO: LOG : fin traitement x 

8 fevr. 2005 09:58:06 f r.ey rol les. exempl es. poa. remplace. UneClasse void uneMethodeO 

INFO: LOG : sortie uneMethode 



Nous constatons que le remplacement s'est effectue a la perfection. 

Analyse du logiciel et tests unitaires 

Dans les sections precedentes, nous avons introduit des techniques modifiant le code 
d'un logiciel pour l'ameliorer. Les techniques de la POA peuvent etre utilisees de 
maniere differente pour analyser le code ou participer a 1' effort de test. 

Bien entendu, ces techniques, materialisees sous forme d' aspects, ne doivent pas etre 
appliquees sur le code compile destine a etre mis en production. II est done necessaire de 
desactiver les aspects au moment de la compilation destinee a produire la version finale 
du logiciel. Pour cela, il suffit d'editer le fichier build.aj properties a la racine du projet 
AspectJ sous Eclipse et de decocher les aspects implementant ces techniques. 
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Analyse d'impacts 

Dans le cadre d'une operation de refactoring, utilisant ou non les techniques reposant sur 
la POA, des classes, des interfaces, des methodes ou des attributs sont destines a etre 
modifies. II est done important d'evaluer les impacts generes par ces modifications avant 
d'effectuer 1' operation. 

La notion de coupe introduite par la POA permet d'intercepter toutes les utilisations d'un 
des elements enonces ci-dessus. Aspect! offre la possibility de generer des avertissements 
(warnings) ou des erreurs de compilation pour chaque interception. 

En listant les avertissements ou les erreurs generes, nous pouvons evaluer les impacts de 
la modification d'un element. 

La figure 7.1 1 illustre le principe de fonctionnement cette technique. 



public aspect Analyse { 
private pointcut detecte () 

declare warning : detecte() 
"Ligne impactee ."; 
} 



public class UneClasse { 
public void methode () { 
methodelmpactee 1(); 



methodelmpactee 2(); 



} 



Figure 7.11 

Analyse d'impacts 



Gains attendus et risques a gerer 

Le gain attendu par 1' application de cette technique est une evaluation precise des 
impacts d'une modification, permettant de decider si cette derniere est justifiee a la vue 
des risques encourus. 

Le risque associe est nul puisque le code du logiciel n'est pas impacte. Si des erreurs de 
compilation sont generees par l'aspect d'analyse, il est impossible de produire un code 
executable. Pour le produire, il suffit soit de le desactiver, soit d'utiliser des avertisse- 
ments a la place. 

Moyens de detection des cas d'application 

Les cas d' application de cette technique sont potentiellement tous les elements concernes 
par une operation de refactoring. Nous conseillons de cibler l'utilisation de cette technique 
aux elements revetant une certaine importance pour le logiciel, 1' etude des resultats produits 
par l'aspect d'analyse pouvant etre tres fastidieuse. 
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Modalites d'application 

L' application de cette technique est simple. II suffit de definir au sein d'un aspect une 
coupe sur l'element a analyser et de l'associer a une declaration d'avertissement (decl are 
warning) ou d'erreur (declare error). 

Exemple de mise en ceuvre 

Supposons que nous ayons derini l'interface et la classe suivantes : 

package f r.eyrol les.exemples.poa. impacts; 

public interface Unelnterface { 
} 

package f r . eyrol 1 es . exempl es . poa . impacts ; 
public class UneClasse implements Unelnterface { 
public void uneMethodetString param) { 

} 

public static void main(String[] args) { 
UneClasse c = new UneClasseO; 
c.uneMethodeC'test") ; 



L' analyse d'impact consiste a detecter les utilisations de l'interface Unelnterface, c'est-a- 
dire les classes qui l'implementent, et les utilisations de la methode uneMethode. Pour cela, 
nous derinissons un aspect comportant une coupe pour chaque cas et une declaration 
d'erreur de compilation associee : 

package f r.eyrol les.exemples.poa. impacts; 

aspect Analyselmpacts { 

private pointcut utiliselnterface( ) ; 
staticinitial i zati on (UneInterface+)&&! within (Unelnterface) ; <— Q 

private pointcut utiliseMethode( ) : 
calKvoid UneClasse. uneMethode(String) ) ; <— © 

declare error : util iselnterfacet ) : 
"Utilise l'interface Unelnterface"; <— © 

declare error : util iseMethodet ) : 
"Utilise la methode uneMethode"; <— © 
} 

La coupe utiliselnterface (repere©) intercepte les implementations de Unelnterface 
(l'operateur + indique l'interface et ses descendants). Pour ne pas generer d'erreur sur 
l'interface elle-meme, cette derniere est exclue du perimetre d' interception (Iwithin). 
La coupe uti 1 1 seMethode (repere ©) intercepte les appels a uneMethode. 
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Chacune de ces deux coupes est associee a une declaration d'erreur de compilation 
(repere ©). Une declaration d'avertissement aurait aussi bien convenu. 

Lorsque nous recompilons notre classe, nous obtenons les erreurs de compilation illustrees 
a la figure 7.12. 
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Figure 7.12 

Resultat de V analyse d' impact 

Nous constatons que l'utilisation de Unelnterface et UneMethode est limitee a UneClasse. 
Leur modification ne devrait done impacter que UneCl asse. 



Respect de contrat 

De nombreuses methodes imposent implicitement des contraintes sur les parametres qui 
leur sont passes et sur les valeurs de retour qu'elles produisent. Par exemple, une 
methode getter sur un tableau possede un parametre representant l'indice de la valeur 
dans le tableau qu'elle doit retourner. Implicitement, cet indice doit etre positif ou nul et 
etre strictement inferieur a la taille du tableau. Rendre ces contraintes explicites peut etre 
extremement couteux en terme de performance, mais peut etre tres utile dans la phase de 
mise au point du logiciel. 

De la meme maniere, les attributs d'une classe peuvent avoir un domaine de valeur plus 
restreint que celui de leur type (par exemple, positif non nul pour un entier). Un controle 
strict permet de gagner en fiabilite au detriment des performances. 

Si des contraintes doivent etre verifiees avant l'execution d'une methode (preconditions), 
nous utilisons un code advice de type before associe a une coupe interceptant les appels 
a la methode ou les modifications de l'attribut contraint. De la meme maniere, la modifi- 
cation de la valeur d'un attribut doit entrainer, le cas echeant, la verification des contraintes 
liees a son domaine de valeur. 

Pour les contraintes portant sur la fin d'execution d'une methode (postconditions), nous 
utilisons un code advice de type after, associe lui aussi a une coupe interceptant les 
appels a la methode. Si une methode donnee possede des contraintes a la fois sur ses 
parametres et sur ses valeurs de retour, nous pouvons n'utiliser qu'une seule coupe, 
commune aux deux codes advice. 
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La figure 7.13 illustre le principe de fonctionnement cette technique. 



public aspect Contrat { 
private pointcut contrat () 

before () : contrat () { 

// Verification des preconditions 
> 

after() : contratQ { 

// Verification des postconditions 
} 
} 



public class UneClasse { 
public void methode () { 

} 



Figure 7.13 

Respect de contrat 



Cette technique est egalement applicable aux contraintes explicites. Ces dernieres peuvent 
etre centralisees au sein d'un aspect interne a une classe, afin d'alleger le code de ses 
methodes, ou modularisees au sein d' aspects de portee plus generale quand il s'agit de 
contraintes transversales a plusieurs classes. 

Gains attendus et risques a gerer 

Grace a la verification du respect des contrats introduite par cette technique, les utilisations 
erronees de methodes sont beaucoup plus facilement detectables. Cela permet souvent de 
trouver des erreurs profondement enfouies dans le logiciel. 

Hormis le probleme de performance lie a 1' utilisation de cette technique, il n'y a pas de 
risque particulier a l'utiliser, sauf celui lie a une mauvaise programmation des contraintes. 

Moyens de detection des cas d'application 

Cette technique est applicable de maniere globale a l'ensemble des methodes et attributs 
d'un logiciel. 

Modalites d'application 

L' application de cette technique est simple. II suffit de definir les contraintes et de les 
coder au sein d'un aspect soit sous forme de code advice before, s'il s'agit de contraintes 
liees a des parametres ou a des attributs, soit sous forme de code advice after, s'il s'agit 
de valeurs de retour. 

Ces codes advice doivent etre associes a des coupes interceptant les appels aux methodes 
ou les modifications des attributs sur lesquels portent les contraintes qu'ils implementent. 

II faut veiller a desactiver les aspects verifiant les contrats lors de la compilation de la 
version de production afin d'eviter les problemes de performance lies a l'utilisation de 
cette technique. 
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Exemple de mise en ceuvre 

Supposons que nous ayons developpe une fonction permettant de calculer la variation en 
pourcentage entre deux valeurs : 

package fr.eyrol les .exemples.poa.contrats; 

public class Calculateur { 

public float cal culeVarPourcentage 
(float plnitiale, float pFinale) { 
return ( (pFinale-pIni ti ale) /plnitiale )*100; 



public static void main(String[] args) { 
Calculateur c = new Calculateur( ) ; 

Sys tern. out. printl n(c.cal culeVarPourcentage (50, 75): 
Sys tern. out. printl n(c.cal culeVarPourcentage (50, 25) ; 
Sy s tern. out. printl n(c. cal culeVarPourcentage (0,25) ) ; 
} 
} 

Si nous l'executons, nous obtenons le resultat suivant : 



50.0 

-50.0 

Infinity 



Comme nous pouvons le constater, aucune erreur n'est retournee par la division par zero 
generee par le dernier appel a cal culeVarPourcentage. Cette methode renvoie en fait la 

valeur inrinie(Fl oat. P0SITIVE_INFINITY). 

Grace aux contrats implementes en POA, nous pouvons detecter de maniere efficace le 
non-respect des contraintes liees a l'utilisation de cal culeVarPourcentage : 

• La valeur initiale ne doit pas etre egale a (precondition). 

• La valeur de retour doit etre comprise entre - 100 et 100 (postcondition). 
L aspect implementant le contrat se presente de la maniere suivante : 

package fr.eyrol les .exemples.poa.contrats; 
aspect Contrat { 



private pointcut calculeVarPourcentage( ) : 
executiontfloat cal culeVarPourcentage( float, float)) 

beforetfloat initiale, float finale) : 
calculeVarPourcentage( ) && argstinitiale, finale) ( 
if (initiale == 0) { 
StringBuffer msg = 
new StringBufferC'ERREUR Precondition : "); 
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msg.appendt "1 a valeur initiale ne peut etre egale a 0"); 
throw new RuntimeException(msg.toString( ) ) ; 



afterO returning (float retour) : calculeVarPourcentage( ) { <— © 
if ((retour < -100) || (retour > 100)) { 
StringBuffer msg = 

new StringBuffer( "ERREUR Postcondition : "); 
msg.appendt "le retour doit etre entre (-100,100). "); 
msg.appendt "Valeurs passees en parametres : "); 
msg. append (t hi sJoinPoint.getArgs( )[0]) ; 
msg.appendt ' , ' ) ; 

msg. append (thisJoinPoint.getArgst )[1]) ; 
throw new RuntimeException(msg.toString( ) ) ; 



La coupe calculeVarPourcentage intercepte l'execution de la methode de meme nom 
(repere ©). Cette coupe est associee a deux codes advice : 

• Le code advice before qui implemente la precondition, puisqu'elle doit etre verifiee 
avant l'execution de la methode (repere ©). 

• Le code advice after qui implemente la postcondition, puisqu'elle doit etre verifiee 
apres l'execution de la methode (repere ©). 

Apres la recompilation et l'execution de notre exemple avec ce nouvel aspect, nous obtenons 
le resultat suivant : 



50.0 


















-50.0 


















java.l ang 


. RuntimeExc 


aption: ERREUF 


Precondition 


la valeur ini 


tiale ne pel 


t etre 


legale a 



















at 


















fr.eyrol 1 


as 


exemples 


.poa.contrats 


Contrat.ajcSbe 


fore$f r_eyrol 1 


es_exempl es_ 


_poa 


*»_contra 


:s_ 


_Contrat$l$8d22903f(Cor 


trat .c 


3:13) 








at 


















fr.eyrol 1 


as 


exemples 


.poa.contrats 


Calcu 


ateur.ca 


1 cul eVarPourcentage( Calcu 


ateur 


.Java) 


















at 


















fr.eyrol 1 


as 


exemples 


.poa.contrats 


Calcu 


ateur.main(Cal cul ateur 


. java:14) 




Exception 


in thread 


'main" 













Nous constatons que notre aspect implementant le contrat de calculeVarPourcentage a 
bien detecte l'utilisation incorrecte de cette methode dans la methode mai n de Cal cul ateur. 
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Tests unitaires de methodes non publiques 

Comme nous l'avons vu au chapitre 5, consacre aux tests unitaires, la verification de 
methodes privees ou protegees avec JUnit necessite de les rendre publiques, introduisant 
ce faisant une faille dans l'isolation des classes concernees, ou de developper les tests 
unitaires sous forme de classes internes, alourdissant en ce cas le code de la classe. 

Grace au mecanisme d' introduction offert par la POA, nous pouvons ajouter des metho- 
des publiques a une classe, ouvrant ainsi l'acces aux methodes privees de cette derniere 
afin de permettre de les tester. Pour eviter tout derapage, les appels a ces nouvelles 
methodes ne sont autorises que dans des tests unitaires, c'est-a-dire des descendants de 

j unit .framework. TestCase. 

La figure 7.14 illustre le principe de fonctionnement de cette technique. 



public privileged aspect TestNonPublic { 

public boolean UneClasse ._methode()4- 
return this .methode()' — ' " 



} 



\ 



\ 



private pointcut interdit () : 



\ 



\ 



V 



declare error : interdit() : 
"Methode reservee aux tests 



} 



public class UneClasse { 
private boolean methode () { 



■//.. 



} 



N 



public class UnTest extends TestCase 

{ 

public void testMethode () { 
\ //... 

assertTrue (c._methode ()) ; 

} 
} 



Figure 7.14 

Test unitaire de methodes non publiques 



Gains attendus et risques a gerer 

L'avantage de cette technique est d'autoriser les tests unitaires de maniere classique, sans 
impacter directement le code de la classe elle-meme. 

Les risques sont nuls, car les appels aux methodes publiques introduites sont proteges, 
toute entorse a la regie etant detectee des la compilation. 

Moyens de detection des cas d'application 

Cette technique est applicable a toute methode privee ou protegee necessitant d'etre 
testee unitairement. 

Modalites d'application 

Les modalites d'application sont simples. Au sein d'un aspect privilegie, nous creons pour 
chaque methode a tester une nouvelle methode publique appelant la premiere. Cette nouvelle 
methode est introduite par AspectJ dans la classe contenant les methodes originelles. 
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Pour terminer, nous creons une coupe detectant les appels aux nouvelles methodes en 
dehors d'un test unitaire (descendant de junit.f ramework.TestCase). Cette coupe est associee 
a une declaration d'erreur de compilation. 

Une fois l'aspect termine, nous pouvons, au besoin, retablir les methodes induiment rendues 
publiques ou extraire les tests unitaires internalises dans les classes. 

Exemple de mise en ceuvre 

Si nous reprenons la classe PersonnePhysique utilisee au chapitre 5, nous pouvons mainte- 
nir la methode rechercheGenre dans son statut prive. 

L aspect suivant va nous permettre de tester cette methode privee : 

package f r.eyrolles.exemples.poa.nonpubl ic; 

privileged aspect TestNonPubl ic { 

public boolean PersonnePhysique. _rechercheGenre <— © 
(char genreRecherche) { 

return this. rechercheGenre (genreRecherche) ; 
} 

private pointcut appelslnterdits( ) : <— © 
call (boolean PersonnePhysique. _rechercheGenre(char)) && 
! within( junit.f ramework.TestCase+) ; 

declare error : appelslnterdits( ) : <— © 
"Appel a _rechercheGenre interdit hors d'un test unitaire."; 
} 

Cet aspect privilegie (mot-cle pri vi 1 eged) est compose de deux parties. La premiere consiste 
a definir la methode publique a introduire dans la classe PersonnePhysique pour permettre 
le test de rechercheGenre (repere©). Cette methode s'appelle ici _rechercheGenre. La 
seconde consiste a prevenir les appels a ^rechercheGenre en dehors des tests unitaires. 
Pour cela, une coupe interceptant les appels a cette derniere (mot-cle cal 1 ) en dehors d'un 
test unitaire (mot-cle within) est creee (repere©). Celle-ci est associee a une declaration 
d'erreur de compilation (repere ©). 

Nous pouvons maintenant modifier notre classe de test en consequence (en gras) : 

package f r.eyrolles.exemples.poa.nonpubl ic; 

import java.util .Date; 

import junit.f ramework.TestCase; 

public class RechercheGenreTest extends TestCase { 

public RechercheGenreTest(String pNom) { 

super(pNom) ; 
} 

public void testFeminin () { 

PersonnePhysique fille = new PersonnePhysiqueC'Dupont" 
, "Jul iette" , ' F' ,new Date( ) ,nul 1 ) ; 
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PersonnePhysique enfants[] = {fille}; 

PersonnePhysique personne - new PersonnePhysiqueC'Dupont" 

, "Emile" , 'M' ,new DateO .enfants) ; 
assertTrue(personne._rechercheGenre( ' F' ) ) ; 
} 

public void testMascul in( ) { 

PersonnePhysique garcon = new PersonnePhysiqueC'Dupont" 

, "Marc" , 'M' , new DateO, null); 
PersonnePhysique enfants[] = {garcon}; 
PersonnePhysique personne = new PersonnePhysiqueC'Dupont" 

, "Emile" , 'M' ,new DateO , enfants) ; 
as sertTrue( per sonne. _rechercheGenre( 'M' ) ) ; 
} 

public void testlndetermineO ( 
PersonnePhysique fille = new PersonnePhysiqueC'Dupont" 

, "Jul iette" , ' F' ,new DateO .null ); 
PersonnePhysique enfants[] - {fille}; 
PersonnePhysique personne ■ new PersonnePhysiqueC'Dupont" 

, "Emile" , 'M' ,new DateO .enfants) ; 
as sert False (per sonne. _rechercheGenre( 'W ) ) ; 



} 



L' execution de cette classe avec un lanceur JUnit fonctionne parfaitement, comme 
l'illustre la figure 7.15. 



Figure 7.15 

Execution du test unitaire avec I 'aspect 
ouvrant I'acces aux methodes non publiques 



Package Explorer ; Hierarchy 



Finished after 0,031 seconds 



» I % ai ' 



Runs: 3/3 H Errors: CI 



^Faiures J* Hierarchy j 



.. o— Em^mgBB 



g3 testFeminin 
eg} testMasculin 
si tesUridetermine 
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Si, par inadvertance, nous utilisons _rechercheGenre en dehors d'une classe de test, par 
exemple, directement dans PersonnePhysi que, nous constatons qu'une erreur de compilation 
est automatiquement generee (voir figure 7.16). 




public boolean possedeFille () { 
char rj^nrfiRer.hfirchF! = r F'; 
I' ::;: ji 5 _-eche-cheGenre ii"€dit -~i~t d'^.n :^;i '..~it3i!^.[ -~ ~,c ~hc r chc ) , 



■ 



private boolean rRr.Tifirrhp^nrR (char gRnrpRpchRrr-fap) { 
boolean trouve — false ; 
int i = 0; 
if (enfants=null) { 

return false; 
} 



JO 



Figure 7.16 

Erreur de compilation generee par AspectJ suite a un appel interdit 



Conclusion 



Ce chapitre a presente un large panel des possibilites de la POA dans le domaine du 
refactoring. Les solutions offertes par la POA sont d'une grande efricacite, mais peuvent 
avoir des effets de bord desastreux si elles ne sont pas utilisees avec precaution. 

Au chapitre suivant, qui clot la partie II, nous abordons les techniques de refactoring liees 
aux bases de donnees. Ces dernieres repondent a des problematiques recurrentes dans les 
logiciels, notamment ceux d'informatique de gestion. 
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Refactoring 
de base de donnees 



Dans les logiciels, notamment ceux destines a l'informatique de gestion, les bases de 
donnees jouent un role preponderant. II est done logique de s'interesser aux techniques 
de refactoring permettant d'ameliorer leur structure et leur acces. 

Nous nous interessons ici exclusivement aux bases de donnees relationnelles, qui sont les 
plus courantes. 

Nous supposons que le lecteur maitrise les concepts des bases de donnees relationnelles, 
du langage SQL et de JDBC (Java DataBase Connectivity). Pour ceux qui ne maitrisent 
pas ces concepts, nous recommandons les ouvrages Introduction aux requites SQL et 
JDBC et Java - Guide du programmeur, parus respectivement chez Eyrolles et O'Reilly. 



La problematique du refactoring avec les bases de donnees 

Les bases de donnees sont generalement un element fondamental des logiciels, leurs 
interactions avec le reste du logiciel etant le plus souvent tres etroites. Comme les bases 
de donnees constituent la couche « basse » du logiciel, tout changement a leur niveau 
peut avoir des repercussions tres importantes sur le reste du logiciel. Par ailleurs, des 
donnees etant stockees dans ces bases, elles sont sensibles aux modifications de la structure 
de ces dernieres. 

Pour toutes ces raisons, les bases de donnees sont un element delicat a refondre puisqu'il 
est necessaire non seulement de realiser des tests de non-regression mais aussi d'effectuer, 
le cas echeant, des migrations de donnees. 
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Outre la structure des bases de donnees, les operations de refactoring peuvent concerner 
les acces a ces dernieres. Elles reposent sur les deux elements complementaires suivants : 

• un middleware, en l'occurrence JDBC, gerant le dialogue avec le SGDB (systeme de 
gestion de bases de donnees) ; 

• un langage de requete (SQL). 

L'essentiel de ces operations de refactoring consiste a ameliorer les performances du 
logiciel. Elles sont nettement plus legeres que des modifications de structure et n'impactent 
generalement pas directement la base de donnees. 



Refactoring de la structure de la base 

Ce type de refactoring consiste a modifier ou enrichir la structure de la base de donnees 
relationnelle et son contenu de maniere a normaliser ou simplifier son utilisation. II s'agit 
la plupart du temps d'operations lourdes, dont l'interet doit etre serieusement evalue par 
rapport aux risques encourus. 

Nous ne presentons ici que quelques operations de refactoring parmi les plus classiques 
dans ce domaine. 

Stockage separe des donnees operationnelles et historiques 

Les donnees operationnelles, c'est-a-dire necessaires au fonctionnement quotidien du 
logiciel, sont stockees dans la meme base que les donnees historiques, non necessaires au 
fonctionnement quotidien du logiciel. Au fil du temps, la base devient obese, et les 
performances se degradent. 

La solution consiste a separer les donnees operationnelles, necessitant de bonnes perfor- 
mances, et les donnees historiques, dont 1' exploitation ne necessite pas le meme niveau 
de criticite. II suffit pour cela de dupliquer la base de donnees puis de supprimer les 
donnees historiques dans la base originale et les donnees operationnelles dans la copie. 

Si un meme logiciel accede a la fois aux donnees operationnelles et aux donnees historiques, 
il est necessaire de l'adapter de maniere qu'il puisse selectionner la bonne base de donnees 
en fonction de ses besoins. 

Enfin, il est necessaire de developper un module d'archivage des donnees capable de 
transferer automatiquement les donnees operationnelles anciennes dans la base de donnees 
historique. 

Gains attendus et risques a gerer 

Une base de donnees obese est par essence longue a sauvegarder et done longue a restaurer 
en cas d'incident. En allegeant la base de donnees operationnelle des donnees historiques, 
nous ameliorons ses performances et facilitons son exploitation. Le reglage du SGBD 
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peut etre optimise specifiquement pour les donnees operationnelles d'un cote et les 
donnees historiques de 1' autre. 

Ce type d'operation est cependant risque. II est d'abord necessaire d'etre capable de deli- 
miter les donnees operationnelles et historiques. Ensuite, le nettoyage et le processus 
d'archivage sont souvent longs a mettre au point et sont susceptibles de comporter des 
erreurs difficiles a detecter. 

Moyens de detection des cas d'application 

Une base de donnees dont la taille croit fortement chaque annee et dont les performances 
se degradent d'une annee sur 1' autre est generalement une bonne candidate a ce genre 
d'operation. 

Exemple de mise en ceuvre 

Les banques sont dans 1' obligation legale de maintenir un historique des mouvements 
bancaires des comptes de leurs clients sur plusieurs annees. Du point de vue du client, 
l'interet d'un tel historique est nul, seuls les quelques derniers mois repondant a ses besoins. 
II est done interessant de separer les donnees historiques des donnees de production. 

Decouplage de la structure de la base et du reste du logiciel 

Les acces a la base de donnees sont disperses dans l'ensemble du logiciel. Toute evolu- 
tion dans la structure de la base impose de modifier un grand nombre de classes, sans 
pouvoir etre sur de l'exhaustivite de la mise a jour. 

La solution consiste a decoupler la structure de la base du reste du logiciel. Cela consiste 
a creer un modele objet metier propre au logiciel, dont la manipulation se fait au travers 
d'une couche d'acces aux donnees. C'est cette couche qui concentre tous les points 
d' adherence entre le logiciel et sa base de donnees. 

Gains attendus et risques a gerer 

En centralisant les acces aux donnees au sein d'une seule couche, nous simplifions l'effort 
de maintenance et garantissons plus facilement la prise en compte exhaustive d'une modi- 
fication de structure. Par ailleurs, si cette couche isole parfaitement les acces a la base du reste 
du logiciel, nous pouvons plus facilement migrer d'un type de base de donnees a un autre. 

Malheureusement, cette operation de refactoring est lourde a mettre en oeuvre et impacte 
une grande partie du logiciel, si ce n'est la totalite, necessitant une revision complete de 
sa conception. 

Moyens de detection des cas d'application 

Pour detecter si le logiciel est un bon candidat, il suffit de rechercher dans l'ensemble des 
classes les references a 1' API JDBC, comme une recuperation de connexion. Si ces references 
sont dispersees de maniere anarchique, elles constituent de bonnes candidates a la refonte. 
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Utilisation des vues 

La structure de la base de donnees impose au logiciel 1' utilisation de nombreuses jointures 
ou conditions de selection dans ses requetes SQL, les rendant difficiles a comprendre et a 
maintenir. 

Pour les jointures frequemment utilisees au sein du logiciel, il peut etre utile de creer des 
vues. Une vue est utilisable via SQL de la meme maniere qu'une table pour la consultation. 
La difference reside dans le fait que la structure et le contenu de la vue sont definis par le 
resultat d'une requete SQL portant sur une ou plusieurs tables. 

Gains attendus et risques a gerer 

Grace aux vues, nous pouvons simplifier les requetes du logiciel parmi les plus difficiles 
a comprendre et a maintenir. 

Le risque d' utilisation de cette technique est faible, car elle n'impacte pas directement la 
structure de la base de donnees et se contente de l'enrichir. L effort de test est bien cible, 
et les requetes sont simplifiees apres la mise en place de la vue. 

Moyens de detection des cas d'application 

Un recensement des requetes et une analyse de leur contenu permettent d'identifier assez 
facilement les opportunites de creation de vues. 

Exemple de mise en ceuvre 

Supposons que nous ayons une table unique pour enregistrer toutes les personnes clientes 
d'une entreprise, qu'elles soient physiques ou morales. Afin de simplifier les requetes ne 
concernant qu'un des deux types de personne, il peut etre interessant de creer une vue 
pour chacun d'eux. 

Utilisation des index 

Certaines selections de donnees avec une clause WHERE dans la base s'averent longues a 
s'executer. 

En fonction des colonnes utilisees dans la clause WHERE, une selection peut necessiter une 
lecture complete de la table (full scan). Cette lecture est d'autant plus longue que la table 
en question est volumineuse. Lutilisation d'index permet d'ameliorer la situation. 

Pour etre efficaces, les index doivent porter sur les attributs utilises dans les clauses WHERE. 

Gains attendus et risques a gerer 

Grace aux index, nous limitons les lectures completes de tables, penalisantes en cas de 
gros volume. 

Cette technique comporte peu de risque puisqu'elle n'impacte pas directement la structure de 
la base de donnees. II faut cependant utiliser les index avec discernement du fait de leur cout 
en terme d'espace disque et de mise a jour, les index devant etre rafraichis pour etre efficaces. 
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Moyens de detection des cas d'application 



Une analyse des performances des requetes effectuees sur la base de donnees permet de 
determiner l'opportunite d'utiliser des index. En regie generale, les principaux SGBD 
proposent des analyseurs de performance des requetes SQL. 

Exemple de mise en ceuvre 

Si nous reprenons notre table unique stockant les clients d'une entreprise, nous pouvons 
constater que les clauses WHERE des requetes SELECT la concernant ne portent pas uniquement 
sur la cle primaire de la table mais que d'autres champs apparaissent tres regulierement. 

Le cas le plus classique est celui de l'utilisation de la colonne contenant le nom du client. Ann 
d'ameliorer les performances des requetes SELECT utilisant cette colonne, il est interessant 
de creer un index portant sur celle-ci. 



Refactoring des requetes SQL 

Les requetes SQL peuvent souvent etre refondues pour etre rendues plus performantes. 

Les sections qui suivent presentent quelques techniques elementaires mais efficaces pour 
une premiere optimisation. 

Limitation des colonnes ramenees par un SELECT 

Les requetes SELECT du logiciel utilisent souvent le caractere * pour recuperer l'ensemble 
des colonnes produites par celles-ci, induisant des temps de reponse un peu longs ou une 
surcharge reseau. 

Le logiciel n'a generalement pas besoin de l'ensemble des colonnes qu'une requete 
SELECT est en mesure de renvoyer. II est done preferable de remplacer l'operateur * par la 
liste exhaustive des colonnes reellement necessaires. 

Gains attendus et risques a gerer 

L'interet de limiter le nombre de colonnes d'une requete SELECT au strict necessaire est 
d'alleger le volume des donnees transmises par le SGBD et d'economiser de ce fait des 
ressources reseau tout en gagnant en performances. 

Les risques a utiliser cette technique sont tres faibles. Le seul danger est de ne pas avoir 
inventorie correctement les colonnes necessaires au logiciel et de generer ainsi des erreurs. 

Moyens de detection des cas d'application 

II suffit de rechercher la chaine de caracteres SELECT * dans l'ensemble des fichiers d'un 
logiciel susceptibles de contenir des requetes SQL pour trouver les candidats a l'utilisation 
de cette technique. 
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Exemple de mise en ceuvre 

Supposons que notre logiciel affiche une liste de clients dont chaque ligne, une par client, 
soit cliquable pour afficher les details du client. Pour creer cette liste, susceptible de 
contenir plusieurs centaines, voire milliers de lignes, il n'est ni inutile ni surtout optimal 
d'utiliser l'operateur * dans la requete. II est preferable de selectionner le minimum de 
colonnes, par exemple la cle primaire, le nom du client et son adresse. 

Limitation des lignes ramenees par un SELECT 

Une requete SELECT renvoie un grand nombre de lignes, dont seule une faible partie est 
reellement utilisee. Or, cette requete est particulierement longue a executer du fait du 
nombre important de lignes. 

La solution consiste a avoir la clause WHERE la plus restrictive possible, c'est-a-dire a defi- 
nir un maximum de contraintes reliees entre elles par l'operateur logique AND. 

Certains SGBD etendent le langage SQL de maniere a limiter le nombre de lignes retournees 
pour une requete SQL. II faut cependant prendre en compte cet ecart vis-a-vis du standard 
SQL si nous voulons garder la possibilite de realiser un portage vers un SGBD different. 

Gains attendus et risques a gerer 

Les gains attendus sont la reduction du volume de donnees transmises par le SGBD, ainsi que 
les economies de bande passante reseau et 1' amelioration des performances qui en decoulent. 

Les risques encourus dependent fortement du contexte, notamment de la complexite du 
filtrage opere par le logiciel et de la facilite de sa traduction en SQL. 

Moyens de detection des cas d'application 

Hormis une revue de code, il n'est pas possible de savoir si la totalite des lignes est neces- 
saire. Nous nous interessons done en priorite aux requetes SELECT les plus couteuses. 

Exemple de mise en ceuvre 

Supposons que la liste des clients contienne des milliers de lignes. Du point de vue de 
l'utilisateur, la recherche du client peut se reveler fastidieuse. C'est la raison pour 
laquelle la liste n'affiche le plus souvent que les clients dont le nom commence par une 
lettre donnee, definie prealablement par l'utilisateur. 

Puisque la liste a afficher est contrainte, il est preferable de faire de meme avec la requete 
SQL, plutot que de tout recuperer en une seule fois et de n' afficher qu'une partie des 
resultats obtenus. 

Limitation des colonnes modifiees par un UPDATE 

Les requetes de mise a jour UPDATE impactent l'ensemble des colonnes d'une table alors 
qu'une seule partie de ces dernieres est reellement concernee. Pour une table avec beau- 
coup de colonnes, les requetes sont difficilement lisibles, et 1' identification des colonnes 
reellement mises a jour est malaisee. 
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La solution consiste a limiter la portee de la requete UPDATE aux seules colonnes modifiees. 

Gains attendus et risques a gerer 

Les gains attendus sont une simplification de la requete, une diminution des risques 
d'erreur dans les mises a jour (par exemple, le report des valeurs sur les colonnes non 
concernees par la mise a jour est-il correct ?) et une diminution de la charge pour le SGBD. 

Les risques d'utilisation de cette technique sont quasiment nuls des lors que les colonnes 
a mettre effective ment a jour sont correctement repertoriees. 

Moyens de detection des cas d'application 

Seule une analyse des requetes UPDATE permet de savoir si elles impactent l'ensemble des 
colonnes d'une table. II est conseille de se concentrer sur les requetes impactant les tables 
ayant un grand nombre de colonnes. 

Exemple de mise en ceuvre 

Si un client change d'adresse, il est preferable de ne modifier que les champs correspondant 
a celle-ci plutot que l'ensemble des colonnes concernant le client. 

Definition des colonnes d'un INSERT 

Les requetes INSERT du logiciel ne precisent pas quelles sont les colonnes remplies par 
l'insertion. De ce fait, le developpeur doit connaitre la structure de la table ainsi que 
l'ordre des colonnes pour comprendre ce qui y est insere. Par ailleurs, les colonnes ne 
necessitant pas de valeur (colonnes facultatives ou calculees) apparaissent inutilement 
(utilisation de la valeur NULL). 

La solution consiste a modifier les requetes INSERT de maniere a specifier explicitement 
les colonnes concernees. 

Gains attendus et risques a gerer 

Les gains attendus sont une meilleure comprehension du contenu de l'insertion et un 
decouplage de la requete vis-a-vis de l'ordre et du nombre des colonnes de la table 
concernee. La table peut plus facilement evoluer, en lui ajoutant une ou plusieurs colon- 
nes optionnelles, par exemple. 

Les seuls risques dans l'utilisation de cette methode sont un inventaire incomplet des colon- 
nes concernees par une insertion et la longueur de la requete en elle-meme. Dans le cas d'une 
table possedant un grand nombre de colonnes, la requete peut devenir extremement longue. 

Moyens de detection des cas d'application 

En utilisant un outil de recherche supportant les expressions regulieres, nous pouvons 
trouver sans difficulte les requetes INSERT ne specifiant pas les colonnes impactees. Par 
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exemple, l'expression reguliere suivante peut etre utilisee avec l'outil de recherche d'Eclipse 
accessible via Edit, Find et Replace : 

insert into [al\w]+ values.* 



Remarque 

Pour pouvoir utiliser les expressions regulieres avec l'outil de recherche d'Eclipse, il ne faut pas oublier de 
cocher la case Regular Expressions dans les options proposees. 



Exemple de mise en ceuvre 

Supposons que nous ayons besoin de creer une nouvelle colonne optionnelle dans la 
table client pour des raisons fonctionnelles. Les requetes INSERT qui ne precisent pas les 
colonnes qu'elles remplissent echouent systematiquement, obligeant les developpeurs a 
les modifier en consequence. 



Refactoring de I'utilisation de JDBC 

Le refactoring de I'utilisation de JDBC au sein des logiciels permet souvent d'ameliorer 
les performances et de diminuer les impacts d'un changement de structure de la base 
de donnees. 

Utilisation de StringBuffer 

L'operateur + est utilise pour concatener des chaines de caracteres, en particulier pour la 
creation de requetes SQL. Cette facon de proceder est simple du point de vue du codage 
mais guere optimale en terme de performances. 

La solution consiste a ne realiser des concatenations qu'avec la classe java.lang. String- 
Buffer. Celle-ci offre plusieurs methodes append offrant le meme niveau de fonctionnali- 
tes que l'operateur +. 

Gains attendus et risques a gerer 

La classe StringBuffer est beaucoup plus efficace que l'operateur + pour realiser les 
concatenations. En effet, ce dernier cree plusieurs objets temporaires en memoire au 
cours de l'operation, contrairement a StringBuffer. 

Le risque a remplacer l'operateur + par StringBuffer est tres faible. Seule une mauvaise 
transformation de la concatenation est possible. 

Moyens de detection des cas d'application 

La detection des cas d'application est assez fastidieuse, l'operateur + pouvant etre utilise 
dans beaucoup de contextes differents de la concatenation de chaines de caracteres. 
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II est recommande de controler en priorite les zones du logiciel ou les requetes SQL sont 
creees, c'est-a-dire proches des appels aux methodes executeQuery et prepareStatement. 

Exemple de mise en ceuvre 

Notre logiciel dispose d'un ecran permettant de saisir trois criteres obligatoires de 
recherche pour trouver un client dont nous ne connaissons pas l'identifiant : nom, type 
(personne morale ou physique) et code postal de l'adresse. 

Le code Java constituant la requete SELECT se presente de la maniere suivante : 



1st 



ring requete = "SELECT id.nom.codepostal FROM clients WHERE nom=' "+nom+" 
AND type="+type+" AND codepostal=' "+codepostal+" ' ; " ; 



II est preferable en terme de performance de remplacer ce code par celui-ci : 

StringBuffer requete = new StringBufferC'SELECT id.nom.codepostal FROM clients 

•WHERE nom-'"); 

requete. append(nom) ; 

requete. appendt " ' AND type="); 

requete. append(type) ; 

requete. appendt " AND codepostal=' ") ; 

requete. append (codepostal ) ; 

requete. appendt "';"); 

// Pour recuperer la chaine de caracteres finale : 

// requete. toStringt ) 

Utilisation d'un pool de connexions 

Le logiciel ouvre et ferme souvent des connexions JDBC. Or celles-ci sont tres couteuses 
du point de vue des performances (entre 300 et 1 000 ms pour ouvrir une connexion). 

La solution consiste a utiliser un pool de connexions, c'est-a-dire un cache contenant 
plusieurs connexions constamment ouvertes. Les pools de connexions ont ete formalises 
sous la forme de l'interface javax.sql .DataSource. Les serveurs d' applications proposent 
tous un pool de connexions implementant cette interface. Le pool de connexions de 
Tomcat est Commons DBCP (voir http://jakarta.apache.org/commons/dbcp/), qui est utilisable 
en dehors de tout serveur d'applications. 

Gains attendus et risques a gerer 

Grace au pool de connexions, les performances sont ameliorees, et les ressources, en 
l'occurrence les connexions JDBC, peuvent etre adaptees en fonction des besoins. 

La mise en place d'un pool de connexions est simple. Le seul risque est de mal dimen- 
sionner le nombre de connexions ouvertes. Si elles sont trop nombreuses, des ressources 
sont consommees inutilement ; si elles ne le sont pas assez, des delais d'attente apparaissent 
au niveau des traitements ayant besoin d'une connexion. 



Techniques avancees de refactoring 

F 'ARTIE II 



Moyens de detection des cas d'application 

II suffit de chercher les utilisations de la methode getConnection de java.sql .DriverManager 
pour evaluer les besoins en terme de pool de connexions. 

Exemple de mise en ceuvre 

Supposons que notre logiciel dispose d'une servlet affichant la liste des clients d'une 
entreprise stockee dans une table unique appelee cl ients. 

Sans pool de connexions, son code est le suivant : 

package fr.eyrol les . exemples. jdbc; 

// imports 

public class ListeClients extends HttpServlet { 

protected void doGet(HttpServletRequest request, 
HttpServletResponse response) 
throws ServletException, IOException { 

response. setContentType(" text /html ") ; 

PrintWriter out = response. getWriter( ) ; 

Connection connexion=null ; 

Statement requete=nul 1 ; 

ResultSet resul tat=nul 1 ; 

try { 

connexion = 

DriverManager. getConnection( "jdbc: . . . " , "user" , "pass" ) ; 
requete = connexion. createStatement( ) ; 
resultat = requete. executeQueryC'SELECT id.nom.codepostal 

FROM clients"); 
out.println("<htmlXheadX/head><body><table>"); 
while (resultat. nextO) { 

StringBuffer ligne = new StringBuffert "<trXtd>") ; 
1 igne. append ( resul tat. getlnt( "id") ) ; 
1 i gne. append ("</td></tr>") ; 
// Etc. 
} 
} catch (SQLException e) ( 

response. sendError(500, "Exception acces SGBD " + e); 
Ifinally { 
if (resultat != nul 1 ) { 
try ( 

resultat. close( ) ; 
} catch (SQLException e) {} 
} 

if (requete != null ) { 
try ( 

requete. closet ) ; 
} catch (SQLException e) {} 
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if (connexion != null ) { 
try { 

connexion. closet ) ; 
} catch (SQLException e) 



out.println("</tableX/bodyX/html>"); 
out. closet ) ; 



Avec un tel mode de fonctionnement, a chaque requete utilisateur portant sur cette servlet, 
une connexion JDBC est ouverte puis fermee peu de temps apres. Si cette derniere est 
fortement sollicitee, cette succession d'ouvertures et de fermetures est tres couteuse, 
surtout si le reste du logiciel fonctionne de la meme maniere. 

II est beaucoup plus efficient d'utiliser un pool de connexions, d'autant que la mise en 
place de ce dernier est simple et impacte a peine le logiciel. 

La premiere etape consiste a le configurer au niveau du serveur d' applications. Pour une 
application Web J2EE, il faut declarer le pool de connexions (en gras) dans le fichier de 
configuration web.xml : 

<?xml version="l .0" encoding="UTF-8"?> 

<!D0CTYPE web-app PUBLIC "-//Sun Microsystems, Inc. //DTD Web Application 2.3 
*»//EN" "http://java.sun.com/dtd/web-app_2_3.dtd"> 
<web-app> 
<displ ay-name>Logiciel </displ ay-name> 
<servlet> 
<servlet-name> Listed ients</servlet-name> 
<servlet-class> 

fr.eyrol les.exemples. jdbc. Listed ients 
</servlet-class> 
</servlet> 
<servlet-mapping> 
<servlet-name>ListeCl ients</servlet-name> 
<url -pattern>/</url -pattern> 
</servlet-mapping> 
<resource-ref> 
<description> 

reference a la ressource BDD pour le pool 
</description> 

<res-ref-name>jdbc/RefactorPool</res-ref-name> 
<res-type>javax.sql .DataSource</res-type> 
<res-auth>Container</res-auth> 
</resource-ref> 
</web-app> 

Le tag <resource-ref> permet de definir de maniere generique le pool de connexions que 
le logiciel utilise. II definit notamment son nom (tag <res-ref-name>) a utiliser dans le 
logiciel. 
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La creation proprement dite du pool de connexions n'est pas prise en charge par le fichier 
web.xml et depend du serveur d' applications. Nous vous invitons done a consulter sa 
documentation pour traiter ce point. 

Une fois le pool de connexions declare, il faut modifier le code de la servlet afin que 
celle-ci 1' utilise. Pour cela, il faut recuperer 1' instance du pool de connexions 
(javax . sql . DataSource) via JNDI et l'utiliser pour recuperer une connexion au JDBC. La 
recuperation de la source de donnee stockee dans la variable dataSource se fait une fois 
pour toutes au moment de 1' initialisation de la servlet (methode init) : 

package fr.eyrol les . exemples. jdbc; 

// imports 

public class ListeClients extends HttpServlet ( 
private DataSource dataSource; 

public void initO throws ServletException ( 
try { 

Context initCtx = new InitialContextO ; 
dataSource = (DataSource) 

initCtx.lookup("java:comp/env/jdbc/RefactorPool " ) ; 
) catch (Exception e) { 

throw new UnavailableException(e.getMessage( ) ) ; 
) 
} 

protected void doGet(HttpServletRequest request, 
HttpServletResponse response) 
throws ServletException, IOException { 

response. setContentType( "text/ html ") ; 

PrintWriter out = response. getWriter( ) ; 

Connection connexion=nul 1 ; 

Statement requete=nul 1 ; 

ResultSet resul tat=nul 1 ; 

try { 

connexion = 

dataSource. getConnecti on ("jdbc: . . . " , "user" , "pass" ) ; 
requete = connexion. createStatement( ) ; 
resultat = requete. executeQueryC'SELECT id.nom.codepostal 

FROM clients"); 
out.println("<html><headX/head><bodyXtable>"); 
while (resultat. nextO) { 

StringBuffer ligne = new StringBuffert "<tr><td>") ; 

1 igne.append(resultat.getlntd) ) ; 

ligne. append("</td><td>"); 

1 igne.append(resultat.getString(2) ) ; 

ligne. append("</td><td>" ) ; 

1 igne. append ( result a t.getStringO) ) ; 

1 i gne. append ("</tdX/tr>") ; 

// Etc. 
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} catch (SQLException e) { 

response. sendError(500, "Exception acces SGBD " 
Ifinally { 
if (resultat ! = null ) { 
try { 

resul tat.close( ) ; 
} catch (SQLException e) {} 
} 

if (requete != null ) { 
try { 

requete. closet ) ; 
} catch (SQLException e) {} 
} 

if (connexion != nul 1 ) { 
try { 

connexion. closet ) ; 
} catch (SQLException e) {} 
} 
} 

out.println("</table></body></html>"); 
out. closet ) ; 



+ e); 



Remarque 

connexi on . cl ose ( ) ne ferme pas la connexion JDBC mais la rend de nouveau disponible dans le pool. 



Fermeture des ressources inutilisees 

Pour acceder aux donnees via JDBC, plusieurs types de ressources JDBC doivent etre 
utilises. Celles-ci sont souvent couteuses en memoire, tant au niveau du SGBD qu'a celui 
du logiciel. II est done important de les fermer systematiquement des qu'elles deviennent 
inutiles. Pour cela, il suffit d'utiliser la methode cl ose. II faut aussi penser a fermer ces 
ressources en cas d'exception. C'est la raison pour laquelle nous utilisons un bloc f i nally. 

Dans le cas d'un pool de connexions, il est important de liberer la connexion apres utili- 
sation arin de permettre aux autres traitements eventuellement en attente d'en beneficier. 

Gains attendus et risques a gerer 

Le principal gain attendu est une economie de memoire et une moindre charge du 
SGBD. Des ressources qui restent ouvertes inutilement peuvent saturer progressivement 
le SGBD et empecher le logiciel de fonctionner (plus de connexion JDBC disponible, 
par exemple). 

Le risque a utiliser cette technique est quasiment nul des lors que nous nous assurons que 
la ressource fermee n'est plus reutilisee par la suite. 
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Moyens de detection des cas d'application 

Le meilleur moyen de detecter des cas d'application est de comparer le nombre de creations 
de Statement, de PreparedStatement et de ResultSet (appels des methodes prepareStatement, 
createStatement et execute) et le nombre de fermetures (appels de la methode cl ose). Pour 
cela, nous pouvons nous aider, par exemple, de 1' aspect d' analyse d'impacts presente au 
chapitre precedent. Le contenu de la vue Eclipse Problems peut etre filtre et colle dans un 
tableur tel que Microsoft Excel. 

Exemple de mise en ceuvre 

La cloture des ressources JDBC se realise generalement au sein d'un bloc finally, 
comme dans 1' exemple de mise en ceuvre du pool de connexions de Tomcat. II est important 
de fermer unitairement chaque ressource en capturant les exceptions. En effet, si tel n'est 
pas le cas, une exception pourrait empecher les ressources suivantes de se fermer puisque 
le flot d'execution est interrompu. 

Nous nous assurons de la sorte que les ressources sont fermees, et ce quel que soit le 
resultat du traitement (fonctionnement normal ou generation d'exception). En effet, la 
generation d'une exception ne ferme pas automatiquement les ressources, ce qui peut 
saturer progressivement le SGBD. 

Le bloc finally suivant s'assure que le statement requete, le resultset resultat et la 
connexion connection d'une methode sont correctement fermes : 

finally { 

if (resultat != null) { 
try { 

resul tat.close( ) ; 
} catch (SQLException e) {} 
} 

if (requete != nul 1 ) { 
try { 

requete. closet ) ; 
} catch (SQLException e) (} 
} 

if (connection != nul 1 ) { 
try { 

connection. close( ) ; 
} catch (SQLException e) {} 
) 



Reglage de la taille du tampon d'un resultset 

Un resultset contient le resultat d'une requete SELECT. Cette derniere comporte generale- 
ment plusieurs lignes. Ann d'optimiser les echanges avec le SGBD, la classe ResultSet 
ne lit qu'une partie de ces lignes a la fois. Pour les requetes generant beaucoup de lignes, 
il peut etre interessant de minimiser le nombre d'acces au SGBD. 
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L'interface java.sql .ResultSet dispose d'une methode setFetchSize permettant de speci- 
fier le nombre de lignes a recuperer a chaque fois. Afin de diminuer le nombre d'acces au 
SGBD, il est interessant de specifier un nombre proche du nombre de lignes produites par 
la requete. Cette technique est interessante des lors que nous savons a l'avance que la 
totalite du resultset est destinee a etre parcourue. 



Important 

Cette technique ne doit pas etre utilisee des lors que le resultset contient des BLOB (Binary Large 
Objects), sans quoi la consommation memoire risque d'exploser. 



Gains attendus et risques a gerer 

En diminuant de maniere importante le nombre d'acces au SGBD pour lire le resultat de 
la requete SELECT, nous ameliorons les performances. 

Le principal risque est une augmentation de la consommation memoire du logiciel 
puisqu'un plus grand nombre de lignes sont stockees dans la memoire de la JVM au 
profit du SGBD. 

Moyens de detection des cas d'application 

Seule une analyse des requetes et de l'utilisation de leur resultat permet de determiner 
des candidats potentiels. 

Exemple de mise en ceuvre 

Si nous savons qu'il y a environ 1 000 clients, nous pouvons fixer la taille du tampon a 1 200 
afin de pouvoir en recuperer la liste en une seule fois. Pour le reglage, il suffit d'inserer la 
ligne suivante dans la servlet precedente entre l'appel a executeQuery et la boucle whi 1 e : 

resultat. setFetchSize (1200); 

Utilisation de noms de colonnes plutot que de numeros 

L'interface Resul tSet propose d'acceder au contenu d'une colonne par son numero. Nous 
sommes alors contraint par l'ordre des colonnes dans la requete SELECT. Cet ordre peut 
etre perturbe, par exemple, suite a une modification de la requete, obligeant a retoucher le 
code Java manipulant le resultset correspondant. 

La solution consiste a n'acceder au contenu d'une colonne qu'a partir de son nom. Ainsi, 
le changement dans l'ordre des colonnes dans le resultset n'a aucun impact sur le code 
Java qui le manipule. 

Gains attendus et risques a gerer 

Grace a cette technique, le code est plus perenne. II n'y a aucun risque a utiliser cette 
technique des lors que nous nous assurons de la bonne correspondance entre le numero 
de la colonne et son nom. 
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Moyens de detection des cas d'application 

Un moyen simple de detecter les cas d'application est de rechercher l'utilisation des 
mefhodes de l'interface ResultSet reposant sur les numeros de colonne. Nous pouvons 
utiliser, par exemple, la technique d' analyse d'impact decrite au chapitre precedent. 

Exemple de mise en ceuvre 

Si nous reprenons notre servlet exemple, nous constatons que le contenu des colonnes est 
accede par le numero de chacune d'elles. Si, pour une raison ou une autre, une colonne 
doit etre inseree au sein de ces trois colonnes, le prenom, l'ordre et done la numerotation 
des colonnes s'en trouvent perturbes. II est done preferable d'acceder au contenu des 
colonnes par leur nom. 

Ainsi, le contenu de la boucle whi 1 e se presente de la maniere suivante : 

1 igne.append(resultat.getlnt("id") ) ; 

ligne.append("</td><td>"); 

1 i gne. append ( res ultat.getSt ring ("nom") ) ; 

ligne.append("</td><td>"); 

1 i gne. append ( res ultat.getStringC'codepostal ") ) ; 

1 i gne. append ("</td></tr>") ; 

Utilisation de PreparedStatement au lieu de Statement 

Une meme requete dynamique, e'est-a-dire construite a partir de variables, est utilisee un 
grand nombre de fois au sein du logiciel. Celle-ci est creee sous forme de statement, 
necessitant chaque fois une interpretation de la part du SGBD pour l'executer. 

Par ailleurs, des controles manuels doivent etre effectues sur les variables utilisees pour 
verifier que leur contenu est conforme aux attentes de la requete (correspondance entre le 
type SQL de la colonne et le type Java de la variable). 

Pour ce type de requete, il est preferable d'utiliser des PreparedStatement, qui sont compiles 
une fois pour toutes par le SGBD et ameliorent ainsi les performances. 



Important 

Le surcout de creation d'un PreparedStatement par rapport a un Statement peut necessiter un grand 
nombre d'utilisations avant d'etre amorti. Ce seuil varie fortement d'un SGBD et d'un driver JDBC a un 
autre. II est recommande de faire des tests pour calculer ce seuil. Par exemple, sur certaines plates- 
formes, un PreparedStatement est amorti en une soixantaine d'utilisations. 



Depuis la version 3.0 de JDBC, les PreparedStatement sont mis en cache automatique- 
ment au niveau de la source de donnees. Le developpeur est done libere de la charge de 
les maintenir ouverts le plus longtemps possible. 

Gains attendus et risques a gerer 

Le gain attendu est une meilleure performance des requetes frequemment utilisees au 
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sein du logiciel. Par ailleurs, le code est plus lisible puisque le PreparedStatement separe 
bien les parties statiques et dynamiques de la requete SQL. Enfin, il offre un meilleur 
niveau de securite en assurant automatiquement un controle du type des variables utilisees 
par rapport aux attentes de la requete SQL. 

Le principal risque est une degradation des performances du fait de l'insuffisance du 
nombre d'utilisations du PreparedStatement. 

Moyens de detection des cas d'application 

La plupart des Statement peuvent etre remplacees par des PreparedStatement. 

Exemple de mise en ceuvre 

Si notre logiciel est dote d'une fonctionnalite permettant d'importer des donnees d'un 
fichier dans notre base de donnees, nous pouvons supposer qu'une meme requete d'insertion, 
aux valeurs pres, va etre executee un grand nombre de fois, c'est-a-dire une fois par ligne 
contenue dans le fichier. 

Le coeur de 1' implementation de cette fonction peut se presenter de la maniere suivante : 

while (!eof) { 

StringBuffer sql = 
new StringBufferC'INSERT INTO clients (id.nom.codepostal ) VALUESC); 
sql .append(id); 
sql . append (", '") ; 
sql .append(nom) ; 
sql .appendC" , '") ; 
sql . append (codepostal ) ; 
requete. executeQuery( sql .toString( ) ) ; 



A chaque iteration, une nouvelle requete doit etre interpretee par le SGBD, ce qui n'est 
pas optimal du point de vue des performances, puisqu'il s'agit toujours du meme type de 
requete. 

En utilisant un PreparedStatement, nous definissons une fois pour toutes la requete et 
simplifions au passage sa construction : 

PreparedStatement requete = connexion. prepareStatementC'INSERT INTO clients 
*•( id.nom.codepostal) VALUESC?,?.?)"); 
whileUeof) { 

requete. setlntd, id) ; 

requete. setString( 2, nom) ; 

requete. setStringO, codepostal ) ; 

requete. executet ) ; 
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Mises a jour en mode batch 

Certains traitements du logiciel necessitent 1' execution de plusieurs requetes indepen- 
dantes les unes a la suite des autres, generalement au sein d'une boucle. Ces requetes 
devraient former un bloc unique a destination du SGBD. 

JDBC permet d'executer une serie de requetes SQL en mode batch, c'est-a-dire d'un seul 
bloc. Cette fonctionnalite est disponible a la fois pour les Statement et les PreparedState- 
ment via la methode addBatch. Une fois le bloc defini, nous pouvons l'executer grace a la 
methode executeBatch. 

Les premiers sont a utiliser si les requetes en question sont differentes les unes des autres 
en terme de structure. Si la meme requete est executee chaque fois, y compris avec des 
valeurs de variables differentes, les seconds sont a privilegier, pour autant que le nombre 
d'executions soit suffisant pour amortir le surcotlt d' initialisation d'un PreparedStatement. 



Remarque 

Les requetes executees dans le cadre d'un batch appartiennent toutes a la meme transaction. II est done 
important de s'assurer que ces requetes sont coherentes d'un point de vue transactionnel. 



Gains attendus et risques a gerer 

Grace a cette technique, la communication avec le SGBD est optimisee, augmentant ainsi 
les performances. 

L utilisation de cette technique ne comporte pas de risque particulier des lors que les requetes 
sont independantes les unes des autres. 

Moyens de detection des cas d'application 

Les methodes qui executent une succession de requetes sont de bonnes candidates. Cepen- 
dant, il est necessaire de s'assurer que celles-ci sont bien independantes les unes des autres. 

Exemple de mise en ceuvre 

Si nous reprenons l'exemple precedent, nous constatons qu'une succession d'ecritures 
dans la base de donnees est operee de maniere successive. Or ces insertions forment un 
tout et peuvent etre transmises en bloc au SGBD. 

Au lieu d'appeler la methode execute a chaque iteration, il est preferable de constituer un bloc 
de requetes dans la boucle whi 1 e. Ce bloc ne sera soumis au SGBD qu'a la fin de la boucle : 

requete. clearBatch( ) ; 
while(leof) { 

requete. setlntd ,1d); 

requete. setString( 2, nom) ; 

requete. setString(3,codepostal ) ; 

requete. addBatch( ) ; 

} 

requete. executeBatch ( ) ; 
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Gestion des transactions 



Par defaut, toute mise a jour ou insertion dans une base via JDBC est automatiquement 
validee (commit). Cette validation est couteuse en performances, et son declenchement 
doit etre optimise. 

Par ailleurs, du code reposant uniquement sur ce mode peut avoir introduit des traitements 
de nettoyage inutiles, la ou une gestion de transaction optimisee aurait suffi. 

La solution consiste a stopper la validation automatique des requetes en utilisant la 
methode setAutoCommit de la connexion. Une transaction, qui comporte une ou plusieurs 
requetes, doit etre validee explicitement en utilisant la methode commit de la connexion. 
En cas de probleme, comme la generation d'une exception, elle doit etre annulee grace a 
la methode rollback. Grace a cette derniere, toutes les modifications introduites par la 
transaction sont automatiquement annulees, et il n'est plus besoin d'effectuer le nettoyage 
soi-meme. 

Nous pouvons aller encore plus loin en reglant de maniere fine l'isolation des transactions, 
c'est-a-dire la tolerance vis-a-vis de l'acces en lecture a des donnees en cours de modifi- 
cation. Le niveau d'isolation est specifie au niveau d'une connexion JDBC via la 
methode setTransactionlsol at ion. 

II existe quatre niveaux d'isolation, classes ci-dessous par niveau de securite croissant, et 
done de performance decroissant : 

• Java. sql .Connection. TRANSACTION_READ_UNCOMMITTED. II s'agit du niveau d'isolation le 
plus faible, offrant done la meilleure execution concourante des requetes. II autorise la 
lecture de donnees non validees dans la base, avec le risque que celles-ci soient invalidees 
par un rollback. 

• Java. sql . Connection. TRANSACTION_READ_COMMITTED. Ce niveau interdit la lecture de lignes 
dont les changements n'ont pas ete valides. 

• Java. sql .Connection. TRANSACTION_REPEATABLEJ*EAD. En plus de 1' interdiction prece- 
dente, ce niveau interdit la lecture repetitive des memes lignes si celles-ci ont ete modi- 
fiees par une autre transaction entre deux lectures. 

• Java. sql . Connection. TRANSACTION„SERIALIZABLE. En plus des interdictions precedentes, 
ce niveau interdit l'ajout ou la suppression de lignes dans les donnees lues a plusieurs 
reprises par une transaction. 

II faut noter que les SGBD ne supportent pas tous ces niveaux d'isolation. 



Important 

Lorsqu'une transaction est enclenchee sans autocommit, il est fondamental de faire un commit ou un 
rollback. Si cela n'est pas effectue, la transaction reste ouverte inutilement et genere des anomalies 
difficiles a detecter. 
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Gains attendus et risques a gerer 

Une optimisation de la gestion des transactions permet d'ameliorer les performances, 
voire de simplifier le code du logiciel quand celle-ci n'a pas ete utilisee. 

Les seuls risques lies a 1' utilisation de cette technique sont de mal delimiter les transactions 
et de choisir un niveau d' isolation trop faible par rapport aux besoins. 

Moyens de detection des cas d'application 

Seule une revue du code mettant a jour la base de donnees permet d' identifier d'eventuels 
cas d'application. 



Exemple de mise en ceuvre 

Dans notre fonction d'importation de donnees, nous pouvons considerer qu'un echec 
quel qu'il soit annule purement et simplement l'operation. Toutes les donnees importees 
avec succes avant 1' echec doivent done etre effacees. 

Par defaut, chaque requete SQL est automatiquement validee. Dans notre exemple, il est 
done souhaitable de passer en mode manuel et de creer une transaction unique pour 
l'ensemble des INSERT de l'importation de donnees : 

try { 

connexion.setAutoCommit(false) ; 

whiledeof) { 

} 

requete. executeBa ten ( ) ; 
connexion.commit( ) ; <— © 
} 

catch (SQLException e) { 
if (connexion!=nul 1 ) { 
try { 

connexion. rol 1 back( ) ; <— Q 
} 
catch(SQLException er) { 



} 

finally { 

} 

Si la requete batch s'execute sans probleme, la transaction est validee (repere ©). En cas 
d'exception, la transaction est annulee, et toutes les donnees inserees sont automatiquement 
supprimees de la base (repere Qi). 
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Remarque 

La version 3.0 de JDBC introduit la notion de point de sauvegarde (java.sql .Savepoint), qui permet 
d'annuler partiellement une transaction. 



Le code suivant n'insere que deux lignes dans la table cl ient. Les deux dernieres, situees 
apres le point de sauvegarde (repere Q ci-dessous) sont annulees par la methode rol 1 back 
(repere 0) : 

connexi on . setAutoCommi t ( f al se ) ; 

Statement requete = connexion. createStatement( ) ; 

requete.executeQueryC'INSERT INTO clients (id.nom.codepos 

VALUESd.'clientl', '61000'); 
requete.executeQueryC'INSERT INTO clients (id.nom.codepos 

VALUES(2.'client2', '22000'); 
Savepoint s = connexion. setSavepoint( ) ; <— © 
requete.executeQueryC'INSERT INTO clients (id.nom.codepos 

VALUES(3.'client3', '60000'); 
requete.executeQueryC'INSERT INTO clients (id.nom.codepos 

VALUES(4.'client4', '75000'); 
connexion. rol Iback(s) ; <— Q 
connexi on. commit ( ) ; 

La validation finale avec la methode commi t est necessaire pour valider les deux premieres 
lignes inserees dans la base. 



tal) 

tal) 

tal) 
tal) 



Conclusion 



Les techniques presentees dans ce chapitre sont elementaires, et done assez simples a 
mettre en oeuvre. Elles visent a traiter de problemes tres frequents dans le code des logiciels. 
Leur mise en oeuvre prend cependant du temps, comme nous le verrons au cours de 1' etude 
de cas de la partie III. 



Partie 



Etude de cas 



Les chapitres precedents ont decrit en detail le processus de refactoring et les techniques 
associees permettant d'ameliorer la qualite d'un logiciel. La presente etude de cas a 
pour objectif de refondre une application existante en appliquant notre methodologie. 

Ann d'avoir une etude de cas la plus realiste possible, nous avons choisi un logiciel 
Open Source dont le code source pouvait etre refondu. Pour faciliter la prise en main 
de l'etude de cas, nous avons selectionne un projet dont l'aspect fonctionnel pouvait 
etre comprehensible par tous. Son volume de code est sufhsamment important pour 
supporter plusieurs techniques majeures de refactoring sans pour autant le rendre difficile 
a apprehender dans sa globalite. 

L'etude de cas deroule le processus du refactoring au travers de trois chapitres : 

• Le chapitre 9 presente le projet Open Source et la maniere de recuperer son code 
source afin que le lecteur puisse l'etudier et realiser lui-meme le refactoring. 

• Le chapitre 10 synthetise les resultats de l'analyse du logiciel et identifie les zones 
qui seront refondues au chapitre suivant. Toutes les zones possibles ne seront pas 
refondues pour des raisons evidentes de place et sont laissees a titre d'exercice au 
lecteur. 

• Le chapitre 11 detaille la refonte des zones identifiees a l'etape precedente et 
deroule la strategie de test pour chacune d'elle. 

Les procedures d' installation des plug-in Eclipse necessaires au refactoring sont indiquees 
en annexe. Si vous utilisez un autre environnement de developpement, nous indiquons, 
lorsqu'ils existent, les logiciels correspondants. 
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Ce chapitre presente les elements cles du logiciel que nous allons refondre. 

Apres avoir fourni les grandes lignes du cahier des charges que nous nous sommes fixe 
pour selectionner le logiciel, nous presentons celui-ci sous ses aspects fonctionnels et 
techniques. 

Pour terminer, nous detaillons les instructions permettant de recuperer son code source. 

Cahier des charges du logiciel 

Comme vous avez du le comprendre a ce stade de votre lecture, le refactoring n'est pas la 
pierre philosophale du developpement logiciel. Une refonte permet certes d'ameliorer la 
qualite d'un logiciel, mais en aucun cas de transformer un logiciel de mauvaise facture en 
une reference en terme de meilleures pratiques. 

Le critere principal de selection du logiciel est son niveau de qualite. Celui-ci est suffisant 
pour que la refonte ne devienne pas une reecriture complete tout en etant perfectible en 
lui appliquant les principales techniques presentees precedemment dans l'ouvrage. 

Le deuxieme critere est l'ouverture du code source. Les projets Open Source offrent de 
formidables opportunites pour s'exercer au refactoring, soit pour s'autoformer, soit, ce 
qui est encore mieux, pour participer a la vie de ces projets. Beaucoup de projets Open 
Source cherchent des developpeurs pour ameliorer leur base de code existante. 

Le troisieme critere est la complexite fonctionnelle et technique. Du point de vue fonc- 
tionnel, il est important que le logiciel soit comprehensible par tous. Peu d'entre nous 
sont au fait des subtilites des metiers financiers ou de la gestion de production, par exemple. 
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Du point de vue technique, les technologies employees par le logiciel doivent etre repandues 
et etre suffisamment simples pour etre aisement comprehensibles. 

JGenea, une solution Java pour la genealogie 

Une fois le cahier des charges defini et des dizaines de projets Open Source passes en 
revue, le choix s'est porte sur la solution JGenea. II s'agit bien d'une solution, car elle 
comprend deux logiciels. 

Ce projet Open Source sous licence GPL (General Public License) est une solution de 
gestion et de publication de donnees genealogiques. Elle permet a ses utilisateurs de gerer 
facilement leurs recherches genealogiques au sein d'une base de donnees relationnelle 
et de les publier sur le Web. 

La solution JGenea comprend deux logiciels ecrits en Java : 

• JGenea Ihm est un logiciel de type client lourd reposant sur l'API J2SE Swing. C'est 
au travers de cet outil que l'utilisateur peut gerer ses informations genealogiques. 

• JGenea Web est une application Web J2EE sans EJB permettant de consulter les infor- 
mations genealogiques stockees dans la base de donnees geree au travers de JGenea 
Ihm. La version utilisee dans cet ouvrage ne permet pas de modifier le contenu de la 
base de donnees. 

Ce projet est heberge sur le portail de developpement Open Source SourceForge.net et 
est accessible par l'URL http://jgenea.sourceforge.net. 

Dans le souci de maintenir une etude de cas de taille raisonnable, seul JGenea Web sera 
etudiee dans cet ouvrage. Nous avons selectionne volontairement JGenea Web 1 .0, une 
version ancienne moins optimisee que celles disponibles dans le gestionnaire de configu- 
ration de SourceForge.net (le referentiel CVS est consultable sur http://sourceforge.net/cvs/ 
?group_ld=47631). 



Architecture de JGenea Web 

JGenea Web est axee sur la consultation d' informations stockees en base de donnees. Son 
architecture est aisee a comprendre, d'autant qu'elle utilise le design pattern MVC 2 (modele, 
vue, controleur avec controleur unique) pour structurer ses composants. L implementation 
de MVC 2 employee est le celebre framework Open Source Struts, version 1.2. 

Pour ceux qui ne connaitraient pas le design pattern MVC 2 ni Struts, la section suivante 
en presente rapidement une synthese. Nous detaillons ensuite chaque partie de rarchitecfure 
de JGenea Web. 

Le design pattern MVC 2 et Struts 

Le design pattern MVC est un modele d' architecture logicielle qui separe de maniere 
claire les preoccupations liees a 1'IHM (la vue), a la logique de controle (le controleur) et 
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au metier (le modele) en les structurant sous forme de composants distincts. En separant 
ainsi clairement ces differentes preoccupations, les impacts dus au changement d'un des 
composants sont minimises pour les autres composants. Ce modele est d'autant plus inte- 
ressant que, d'une maniere generale, 1'IHM subit beaucoup plus de changements que le 
metier. Le fort degre d'isolation apporte par MVC permet par ailleurs de diminuer les 
couts de maintenance. 

MVC est un design pattern eprouve, mis au point en 1979 pour le langage Smalltalk, 
precurseur de bien des design patterns utilises aujourd'hui en Java. II beneficie de 
nombreuses implementations sous forme de frameworks reutilisables, dont le plus connu 
pour Java est Struts, que nous presentons plus loin. 

La figure 9.1 illustre le principe de fonctionnement du modele MVC. 



Figure 9.1 

Le design pattern MVC 




1. Un evenement est genere par l'utilisateur en reponse a la manipulation de 1'IHM, un 
clic sur un bouton, par exemple. 

2. Cet evenement est recu et analyse par le controleur arm de mener les actions neces- 
saires sur le modele, comme une mise a jour des donnees. Le modele notifie au 
controleur le bon ou mauvais deroulement des actions declenchees par celui-ci. 
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3. En fonction de la notification, le controleur fait appel a la vue correspondante, modifiant 
ainsi 1'IHM manipulee par l'utilisateur, ce qui demarre un nouveau cycle d' interaction. 
La vue peut faire appel au modele en lecture pour afficher des donnees. 



Remarque 

MVC est le design pattern preconise par Sun pour I'architecture d'applications interactives (voir Designing 
Enterprise Applications with J2EE Platform, Second Editionj. 



MVC existe en deux versions, appelees respectivement modele 1 et modele 2. Dans le 
modele 1 , la logique de controleur est totalement decentralisee. II existe a peu pres autant de 
controleurs que de vues. Le modele 2, aussi appele MVC 2, centralise la logique de controle 
au sein d'un controleur unique. C'est le modele preconise par Sun et utilise par Struts. 

L' implementation Struts de MVC 2 est illustree a la figure 9.2. 



Reponse HTTP 




Figure 9.2 

Implementation du design pattern MVC 2 par Struts 
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Nous reconnaissons immediatement la structure du design pattern MVC. L'evenement 
sollicitant le controleur est dans le cas de Struts une requete HTTP envoyee depuis un 
navigateur Web (etape 1) puisque ce framework se destine a fournir une architecture 
MVC aux applications Web. Cette requete est interceptee par une servlet unique de type 

org. apache. struts .action.ActionServlet. 

La requete est traitee au sein d'un processeur de requetes (etape 2) afin de valider les donnees 
transmises par la requete et remplir un Bean de type org. apache. struts. action. ActionForm 
avec ces dernieres. Pour identifier Taction a declencher correspondant a la requete, le 
processeur utilise des informations de mapping fournies dans le fichier struts-config.xml 
(stocks dans le repertoire WEB-INF de 1' application Web). 

Chaque action est definie sous la forme d'une classe de type org . apache . struts . acti on . Acti on 
et comporte une methode execute appelee par le processeur (etape 3). Cette methode 
prend notamment en parametre les donnees recuperees au sein de la requete HTTP sous 
la forme d'un Bean ActionForm. C'est au sein de chaque classe Action que le modele est 
accede. Struts ne specifie pas la nature du modele ni la facon dont il doit etre accede. Cela 
permet d'interfacer Struts avec du code Java classique, des EJB, etc. 

A la fin de T execution d'une Action, celle-ci produit un statut au processeur de requete. 
Ce statut est confronte au mapping defini dans struts-config.xml pour identifier la 
prochaine etape. En regie generale, il s'agit de l'affichage d'une vue. 

La vue au sens Struts consiste en une page JSP utilisant eventuellement les taglibs four- 
nies par Struts pour afficher le resultat de Taction. 

Pour en savoir plus sur le fonctionnement de Struts, voir notamment Touvrage Jakarta Struts 
par la pratique, paru aux editions Eyrolles. 

La partie vue de JGenea Web 

Conformement a T architecture definie par le framework Struts, JGenea Web implemente 
la partie vue du design pattern MVC 2 sous forme de pages JSP. 

Celles-ci, au nombre de 32, utilisent les taglibs de Struts pour recuperer les donnees a 
afficher, transmises par Taction ayant declenche leur affichage, et effectuer des affichages 
conditionnels. 

La figure 9.3 illustre la majeure partie de Tarborescence de JGenea Web. 

L organisation des pages de JGenea Web est typique d'un logiciel de consultation 
d' informations. La plupart des rubriques sont organisees sous la forme d'un formulaire 
de recherche, d'une liste de resultats et d'une fiche permettant de consulter le detail d'un 
resultat. 



Remarque 

La fiche concernant une personne donne acces a deux pages permettant de visualiser son arbre genea- 
logique, respectivement ses ascendants et descendants. 
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Figure 9.3 

Organisation de la partie vue de JGenea Web (extrait) 



L' ensemble des pages JSP est centralise dans le repertoire jsp du projet. 

La partie controleur de JGenea Web 

La partie controleur de JGenea Web est constitute du fichier struts-config.xml pour la 
configuration du controleur Struts et d'un ensemble de classes derivant de classes Struts 
centralisees dans un package Java unique, appele org.genealogie.web. 

Ces classes, au nombre de 38, sont derivees d' Action pour les interactions avec la partie 
modele et d'ActionForm pour stacker les informations saisies par les utilisateurs dans les 
formulaires de recherche proposes par 1' application (une classe par formulaire). 

Toutes les actions de JGenea Web deriventde la classe org.genealogie.web.CheckAction, a 
l'exception de LoginAction et LogoutAction. Cette classe centralise la mecanique de secu- 
rite et de filtrage des informations genealogiques en fonction des droits dont beneficie 
l'utilisateur. 

JGenea Web est construit autour du triptyque recherche, liste des resultats et fiche 
detaillee. Le schema UML illustre a la figure 9.4 illustre les relations entre les 
actions et les actionForms Struts ainsi que les pages JSP (partie vue) pour la recherche 
sur les villes. 
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Figure 9.4 

Diagramme UML du controleur de JGenea Web pour la recherche sur les villes 



La recherche sur les villes fonctionne de la maniere suivante : 

1. La page JSP rechercher_villes.jsp affiche le formulaire permettant a l'utilisateur 
de saisir les criteres de recherche. Ces criteres sont stockes dans une instance de la 
classe RechercherVilleForm. 

2. La classe RechercherVilleAction est instanciee par le controleur Struts. Linstance 
effectue tout d'abord un controle sur les autorisations de l'utilisateur (comportement 
herite de CheckAction). Ensuite, les informations stockees dans l'instance de 
RechercherVi 1 1 eForm sont utilisees pour interroger le modele. 

3. Si au moins une ville est trouvee, une redirection vers liste_villes.jsp est effectuee. 
Sinon, c'est une redirection vers rechercher_villes.jsp qui est effectuee. 

4. Lorsque l'utilisateur clique sur une des villes affichees par liste_villes.jsp, le controleur 
instancie la classe FicheVilleAction. La encore, un controle d'autorisation est effec- 
tue. Le modele est interroge pour recuperer les informations detaillees sur la ville 
selectionnee. 
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5. Ces informations sont passees a la page JSP fiche_ville.jsp pour affichage. 
Cette modelisation est valable pour la majorite des fonctionnalites de JGenea Web : 

• recherche sur les tables ; 

• recherche sur les actes ; 

• recherche sur les documents ; 

• recherche de consanguinite ; 

• recherche sur les personnes. 

Les autres fonctionnalites sont structurees de maniere similaire, mais generalement avec 
une etape en moins (pas de formulaire ou pas de liste ou pas de Ache detaillee). 

L' ensemble des sources de JGenea Web est stocke dans le repertoire WEB-INF/src du 
projet, exception faite des tests unitaires stockes dans un repertoire specifique appele 
tests. 

La partie modele de JGenea Web 

La partie modele de JGenea Web est repartie sur plusieurs packages Java : 

• org.genealogie.arbre : contient les classes permettant de construire un arbre genea- 
logique. 

• org . geneal ogi e . consangui ni te : contient un moteur de calcul permettant de determiner 
le degre de consanguinite entre deux personnes. 

• org. genealogie.ejbs. sessions et org.genealogie.ejbs.entites : contiennent un ensemble 
de classes permettant d'acceder aux informations de la base de donnees genealogique. 
Contrairement a ce que pourrait laisser penser le nom de ces packages, les classes 
qu'ils renferment ne sont pas des EJB (en fait, elles l'etaient a l'origine). 

Ces deux derniers packages constituent le cceur du modele de JGenea Web et sont a ce 
titre des cibles de choix pour le refactoring. 

Le package org.genealogie.ejbs.entites.personne contient les deux classes suivantes : 

• PersonneBean, qui permet d'acceder aux informations concernant une personne donnee. 

• PersonnePK, qui est une representation de la cle primaire utilisee par la base de donnees 
pour identifier une personne. 

Le package org. genealogie. sessions. genealogie contient les autres classes suivantes 
permettant d'acceder au reste du contenu de la base de donnees : 

• Authenti f i cati onBean : permet de recuperer les autorisations d'un utilisateur a partir de 
son login et de son mot de passe. 

• DocumentsBean : permet de consulter les documents genealogiques enregistres dans la 
base de donnees. 
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• Fami 1 1 esBean : permet de consulter les informations sur les families stockees en base 
de donnees. Cette classe comprend des methodes permettant de modifier les donnees 
stockees dans la base genealogique, mais qui ne sont pas utilisees par JGenea Web. 

• TablesRegistresBean : permet de consulter les informations des tables et registres 
communaux stockees dans la base de donnees. 

• GenealogieBean : offre un grand nombre de methodes pour acceder aux informations 
concernant les personnes, les actes, les communes, les departements et les pays stockes 
dans la base de donnees. 

Ces packages utilisent les classes du package org.genealogie.utils, qui sont pour 
l'essentiel des JavaBeans permettant de stacker en memoire les informations lues dans la 
base de donnees. 

Le SGBDR sous-jacent a JGenea Web est HSQLDB. II s'agit d'un SGBDR Open Source 
entierement ecrit en Java. C'est un moteur extremement leger, qu'il est facile d'embar- 
quer dans un logiciel. II est done particulierement adapte a notre etude de cas puisqu'il ne 
necessite pas de parametrage particulier. II supporte une grande partie de la norme SQL 
ANSI-92 ainsi que quelques extensions des normes 99 et 2003. II peut etre telecharge 
gratuitement sur http://hsqldb.sourceforge.net/. 

Le schema de la base de donnees de JGenea Web est fourni en annexe. 



Remarque 

Les classes appartenant a la partie modele sont partagees avec JGenea Ihm. C'est la raison pour laquelle 
certaines de ces classes contiennent des methodes permettant de mettre a jour la base de donnees alors 
que ce n'est pas la vocation de JGenea Web. 



Recuperation de JGenea Web 

Pour la gestion de configuration de notre refactoring, nous nous reposons sur CVS. Pour 
realiser cette etude de cas, un module specifique a ete cree dans le referentiel CVS de 
JGenea heberge sur le site communautaire Open Source SourceForge.net. 

Ce referentiel est public et peut etre consulte par tous de maniere anonyme. Vous l'utiliserez 
pour recuperer les sources de JGenea Web afin de les modifier. Cet acces public est en 
lecture seule. Vous n'aurez done pas la possibilite de remonter vos modifications dans le 
referentiel. 

Pour commencer I'etude de cas, il est necessaire de recuperer la version originale de 
JGenea Web. Pour cela, vous allez utiliser le client CVS integre a Eclipse. Pour les 
lecteurs desirant utiliser un autre environnement de developpement, nous conseillons de 
consulter la documentation fournie par SourceForge.net pour le configurer correctement 

(http://sourceforge.net/docman). 

Avant de recuperer JGenea Web dans Eclipse, vous devez installer Tomcat puis le plug-in 
Eclipse Tomcat de Sysdeo (voir en annexe). 
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Pour les lecteurs ne pouvant ou ne desirant pas utiliser le referentiel CVS de JGenea 
Web, une extraction des differentes versions du logiciel est disponible sur le site Web de 
l'ouvrage. Vous pouvez aussi consulter le contenu du referentiel a l'aide d'un navigateur 
Web a l'URL http://cvs.sourceforge.net/viewcvs.py/jgenea. 

Connexion avec le referentiel CVS 

Sous Eclipse, la connexion avec un referentiel CVS est geree en standard par une pers- 
pective dediee, CVS Repository Exploring. Pour l'ouvrir, il suffit de choisir Window, 
Open Perspective et Other et de la selectionner dans la liste. 

Pour declarer un referentiel CVS, il suffit de cliquer sur le bouton @l , accessible dans la 
barre d'outils de la vue gauche d'Eclipse. Un assistant s'affiche alors, demandant les 
informations necessaires pour se connecter au referentiel, comme illustre a la figure 9.5. 



Figure 9.5 

V assistant de connexion 
a un referentiel CVS 
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Pour vous connecter au referentiel heberge sur SourceForge.net, il suffit d'entrer les 
informations suivantes : 

• Host : entrez cvs.sourceforge.net si votre pare-feu permet une connexion au port TCP/ 
IP 2401 (le port par defaut du protocole pserver). Sinon, entrez cvs-pserver.sf.net, qui 
utilise le port TCP/IP par defaut des sites Web. 
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• Repository path : entrez /cvsroot/jgenea. 

• User : entrez anonymous. 

• Password : il n'y a pas de mot de passe. 

• Connection type : selectionnez pserver. 

• Cochez la case Use Default Port si votre pare-feu autorise le port 2401. Sinon, cochez 
la case User Port, et entrez 80 dans le champ correspondant. 

• Cochez la case Validate Connection on Finish. 

• Cochez la case Save Password. 

Pour terminer, il vous faut cliquer sur le bouton Finish. Eclipse tente alors de se connecter 
au referentiel CVS pour valider les informations fournies a 1' assistant. 

Une fois la connexion etablie, vous pouvez explorer le contenu du referentiel. Pour cela, 
il suffit de developper l'arbre disponible sous forme retractee dans la vue gauche d' Eclipse, 
comme illustre a la figure 9.6. 
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Figure 9.6 

Exploration du referentiel CVS de JGenea 
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L'affichage du detail d'un noeud n'est pas immediat du fait du telechargement des infor- 
mations depuis le referentiel CVS, indique par la mention Pending dans la fenetre. 

Comme vous pouvez le voir sur la figure, un module appele jgenea-refactoring comprend 
une version, ou cliche, appelee ORIGINAL. 

Vous utiliserez ce module jgenea-refactoring pour l'etude cas. La version ORIGINAL 
contient une version de JGenea Web vierge de tout refactoring. 



Recuperation du code de JGenea Web 

CVS permet de gerer les versions successives d'un projet Eclipse. Le module jgenea-refacto- 
ring contient ainsi tous les constituants d'un projet Eclipse. Pour vous familiariser avec le 
code de JGenea Web et derouler vous-meme le processus de refactoring, nous vous 
conseillons de recuperer la version ORIGINAL dans votre environnement de developpement. 

Cette operation est tres simple grace a 1' assistant de creation de projet, accessible via 
File, New et Project. Dans 1' assistant, il suffit de cliquer sur le dossier CVS et de selec- 
tionner Checkout Projects from CVS. Apres avoir clique sur le bouton Next, 1' assistant 
vous demande de selectionner le referentiel CVS source. Selectionnez le referentiel 
declare a la section precedente. 

Apres avoir clique sur le bouton Next, selectionnez l'option Use an existing module. La 
liste des modules presents dans le referentiel s'affiche, et vous pouvez selectionner 
jgenea-refactoring, comme illustre a la figure 9.7. 

Figure 9.7 
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Dans l'etape suivante, accessible apres avoir clique sur Next, l'assistant vous demande le 
nom du projet Eclipse destinataire. Nous vous conseillons de creer un nouveau projet et 
d'utiliser la valeur par defaut, c'est-a-dire le nom du module CVS, jgenea-re factoring. 

Apres avoir clique sur Next et specifie la localisation du projet sur votre poste de travail 
(a noter sur un papier pour une utilisation ulterieure), cliquez sur Next, et selectionnez la 
version du projet a recuperer depuis le referentiel. Dans votre cas, recuperez la version 
ORIGINAL, comme illustre a la figure 9.8. 
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Figure 9.8 

Selection de la version ORIGINAL 

Si ORIGINAL n'apparait pas, cliquez sur le bouton Refresh from Repository. 



Remarque 

La selection de HEAD vous permet de recuperer les toutes dernieres revisions du contenu du module 
jgenea-refactoring. 



Cliquez sur le bouton Finish. Eclipse cree le projet jgenea-refactoring et le remplit avec 
les ressources stockees dans le referentiel CVS. Pour le constater, vous pouvez ouvrir la 
perspective Java et consulter le nouveau projet jgenea-refactoring, qui doit avoir l'aspect 
illustre a la figure 9.9. 
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Figure 9.9 

Le projet Eclipse JGenea Web 
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acme.jar 1.1 (Binary) 

antlr.jar 1.1 (Binary) 
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commons Hc.upload.far 1.1 (Binary) 
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em ma ant jar 1.1 (Binary) 

em ma .jar 1.1 (Binary) 

hsqldb.jar 1,1 (Binary) 
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]akarta-regexp-1.2.jar 1.1 (Binary) 
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struts.jar 1.1 (Binary) 
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commons-pool-1.2.jar 1.1 (Btiary) 

tests 
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Si vous rencontrez des problemes de depassement de delai vous empechant de recuperer 
completement le projet, vous devez augmenter la valeur du champ Communication 
timeout dans la rubrique Team\CVS, accessible via Window et Preferences. 



Parametrage et validation 

Vous allez maintenant effectuer les dernieres taches necessaires pour obtenir une version 
de JGenea Web pleinement operationnelle dans votre environnement de developpement. 

Apres avoir installe et configure Tomcat puis le plug-in Eclipse Tomcat de Sysdeo (voir 
en annexe), il vous faut configurer le projet de maniere qu'il soit bien pris en compte par 
ces derniers. 

La premiere etape consiste a ouvrir les proprietes du projet jgenea-refactoring (accessibles 
par clic droit sur le projet et en selectionnant Properties dans le menu contextuel) et a 
verifier que la rubrique Tomcat contient les informations illustrees a la figure 9.10. 
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Properties for jgenea-refactoring 
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Figure 9.10 

Configuration Tomcat du projet 



Dans le menu contextuel du projet (accessible par clic droit sur le dossier du projet), selec- 
tionnez Projet Tomcat et Declarer les librairies Tomcat dans le chemin de compilation du 
projet. Cette operation doit supprimer les erreurs de compilation que vous pouvez avoir 
rencontrees lors du telechargement du projet. Si tel n'est pas le cas, verifiez que le reper- 
toire d'installation de Tomcat que vous avez specifie au plug-in est correct (voir en annexe). 

Toujours dans le menu contextuel du projet, selectionnez Projet Tomcat et Mise a jour du 
contexte. 

II vous faut ensuite modifier le fichier struts-config.xml stocke dans le repertoire WEB- 
INF. Dans la section du fichier destinee a la declaration des sources de donnees, il est 
necessaire de faire pointer la propriete url de la source de donnees Perso vers les fichiers 
de donnees jgenea (en gras ci-dessous) : 

<data-source key="Perso" 

type= "org. apache. commons. dbcp.BasicDataSource"> 
<set-property property ="dri verCl ass Name" 

val ue="org.hsqldb. jdbcDri ver" /> 
<set-property property="url " 

val ue="jdbc:hsqldb:C:\Eclipse\workspace\jgenea- 
refactoring\db\jgenea" /> 
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Le repertoire db est un sous-repertoire de l'emplacement du projet Eclipse que vous avez 
defini lors de la recuperation dans CVS. 

Pour terminer, il vous faut editer le fichier Conf.properties situe dans le package 
properties du repertoire de code source WEB-INF/src. La valeur de la variable IMAGES doit 
contenir le chemin vers le repertoire contenant les images du projet (pour les utilisateurs 
de Windows, il faut utiliser / au lieu de \) : 

IMAGES=C:/Ecl ipse/workspace/jgenea-refactoring/img 

Une fois les fichiers mis a jour, si necessaire, vous pouvez executer Tomcat en cliquant 
sur le bouton sg], disponible dans la barre d'outils d'Eclipse. 

Une fois le lancement de Tomcat termine (la vue Console est accessible via Window, 
Show View et Console), il suffit de lancer un navigateur Web et de saisir l'URL http://local- 
host:8080/JGenea- Web. 

Une page d'identification apparait, comme illustre a la figure 9.1 1. 
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Figure 9.11 

Page d'identification de JGenea Web 



L'identifiant est admin et le mot de passe admin. Vous pouvez maintenant utiliser les diffe- 
rentes fonctionnalites offertes par JGenea Web. 
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Fonctionnalites d'Eclipse utiles pour I'etude de cas 

Quelques fonctions d'Eclipse vous seront particulierement utiles pendant le processus de 
refactoring. Elles sont presentees de maniere synthetique dans les sections suivantes. 

Fonctionnalites du client CVS 

Les fonctionnalites du client CVS dont dispose Eclipse sont accessibles depuis le menu 
contextuel de la vue Package Explorer, dans les rubriques Team, Compare With et Replace 
With (voir figure 9.12). 
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Figure 9.12 

La rubrique Team 



La rubrique Team, dont le role est de mettre a jour le referentiel CVS, n'est pas utilisee 
dans le cadre de cette etude de cas. La connexion utilisee etant en lecture seule, vous ne 
pourrez pas soumettre vos travaux dans le referentiel. 

Les deux autres rubriques vous seront particulierement utiles. La premiere vous permet 
de comparer le code de JGenea Web stocke dans votre projet Eclipse local avec 
n'importe quelle version, branche ou revision du code disponible dans le referentiel (voir 
figure 9.13). Elle vous permettra de comparer notamment les modifications introduites a 
chaque etape majeure de votre refactoring. 

La version nommee HEAD correspond par defaut dans CVS a la version de code la plus 
recente disponible dans le referentiel. 
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Figure 9.13 

Comparaison entre deux versions d'un meme fichier 



La rubrique Replace With vous permet de remplacer le code stocke dans votre projet 
Eclipse local par n'importe quelle version, branche ou revision du code disponible dans 
le referentiel. Pour remplacer un projet complet, il vous suffit d'acceder au menu contextuel 
en selectionnant la racine du projet dans la vue Package Explorer. 

Cette fonctionnalite vous sera utile pour recuperer les differentes versions de JGenea 
Web qui correspondent a chaque etape majeure du processus de refactoring. 

Fonctionnalites de recherche dans le code 

Eclipse dispose de fonctions de recherche puissantes, qui s'averent tres utiles dans le 
cadre d'un refactoring. Ces fonctions sont toutes accessibles depuis le menu Search illustre 
a la figure 9.14. 
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Le sous-menu Java vous permet de rechercher classes, mefhodes, constructeurs, attributs 
ou packages dont le nom est specifie en critere de recherche (voir figure 9.15). Le moteur 
de recherche permet de trouver soit la declaration, soit les references dans le code, soit 
les deux. La portee de la recherche peut etre limitee afin de limiter le nombre de resultats 
trouves. La recherche des references est particulierement utile pour le refactoring, car 
elle permet de se faire une idee des impacts lies a la modification d'un element Java. 
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Figure 9.15 

Recherche de code Java 



Les sous-menus References, Declarations, Implementors, Read Access et Write Access 
offrent des acces directs aux differents types de recherches disponibles dans le sous- 
menu Java. 

Grace au sous-menu File, vous pouvez effectuer des recherches dans les autres types de 
fichiers (XML, JSR etc.) et utiliser des expressions regulieres, qui offrent une grande 
puissance d' expression du critere de recherche. 



Conclusion 



Comme vous avez pu le constater dans ce chapitre, 1' architecture de 1' application JGenea 
Web est facile a comprendre. 

Au chapitre suivant, vous analyserez cette application en profondeur afin de detecter les 
candidats au refactoring. Pour cela, vous utiliserez l'environnement Eclipse tel que confi- 
gure dans ce chapitre, auquel vous ajouterez des plug-in necessaires a 1' analyse. 
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Analyse 
de JGenea Web 



Au chapitre precedent, vous avez recupere la version originale de JGenea Web sous la 
forme d'un projet Eclipse et avez verifie qu'elle fonctionnait correctement dans votre 
environnement. 

Vous pouvez maintenant analyser ce logiciel a l'aide des outils et methodes presentes a la 
partie II de cet ouvrage. 

Vous procederez dans l'ordre suivant : 

1. Analyse quantitative fondee sur les statistiques de bogues, les statistiques du referen- 
tiel CVS et les metriques logicielles. 

2. Analyse qualitative fondee sur les outils d' audit de code et une revue d' architecture. 

Apres avoir identifie les points faibles de JGenea Web, vous selectionnerez les zones que 
vous refondrez au chapitre suivant. 

Pour realiser les exercices de ce chapitre, il est necessaire d' avoir installe au prealable les 
logiciels suivants (pour les procedures d' installation, voir en annexe) : 

• StatCVS 

• PMD 

• Metrics 
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Analyse quantitative 

L' analyse quantitative permet d'obtenir des indicateurs sur la qualite des differents 
composants de JGenea Web et de guider ainsi 1' analyse qualitative qui la suit. 

Informations sur la documentation du code 

Java impose une norme de documentation du code, appelee javadoc. Par defaut, le 
compilateur ne produit pas d'alerte lorsque la documentation est absente. II est possible 
de modifier son parametrage pour produire des avertissements signalant le code incrimine. 

Dans Eclipse, le parametrage du compilateur Java peut etre modifie en choisissant 
Window et Preferences et en selectionnant la sous-rubrique Compiler de la rubrique Java. 
L'onglet javadoc permet de selectionner les differents controles a operer. 

Si vous cochez les options Missing Javadoc Tags et Missing Javadoc Comments avec un 
niveau private, vous obtenez plus de mille avertissements apres une recompilation du projet. 

La documentation de ce projet est done insuffisante et peut s'averer problematique lors 
du refactoring du code. 

Statistiques sur les bogues 

La solution Open Source JGenea etant hebergee sur le portail de developpement Source- 
Forge. net, elle beneficie de son gestionnaire d'anomalie. Celui-ci est plus simple que 
BugZilla, que nous avons presente au chapitre 6, tout en fournissant l'essentiel des fonc- 
tionnalites necessaires. 

Le gestionnaire d'anomalie de JGenea est accessible publiquement a l'URL http://source- 
forge.net/projects/jgenea/. Dans la section Public Areas, cliquez sur le lien Bugs pour acceder 
a l'interface de consultation des anomalies illustree a la figure 10.1. 

L interface de consultation vous permet de definir des criteres de selection pour n'affi- 
cher que les anomalies qui vous interessent. Comme vous vous interessez au passe de 
JGenea, vous devez modifier le statut des bogues. Par defaut, ce statut est Open, e'est-a- 
dire que seules les anomalies non corrigees sont affichees. Vous devez le changer en 
Closed afin de visualiser les anomalies corrigees dont la correction est susceptible de 
degrader la qualite du code. 

Si vous deroulez la rubrique Category, vous vous apercevez qu'il existe deux categories 
susceptibles de correspondre aux bogues declares pour JGenea Web : Web et Web Serv. 
Malheureusement, aucune ne contient d'anomalies. 

JGenea Web partageant une partie de son code source avec JGenea Ihm, il est necessaire 
de passer en revue 1' ensemble des anomalies, au nombre de 72 au moment de l'ecriture 
de cet ouvrage. 



Analyse de JGenea Web 

Chapitre 10 



Project: 


JGenea: Browse Bugs 










Summary | Admin \ Home Page | Forums | Tracker | Bugs | Support | Patches ] RFE [ Lasts | Tasks \ Docs | Sc 
News | CVS | Files | Donations j 


reenshots | 


Login and S. 

Assignee: (?} 

Any 
Request ID 


ubmit New | Browse | Admin | Search 

Status: (?) Category: {?) Group 

Open - Any v Any 


-in , 

l 


riority Assigned Tc 




imirlpr nqprnflmp 1 SiLmfnnry k— va n rrl ■ 








SDriBy:[?).|lD Descending v| | Browse | 

Summary Open Date P 


Submitted By 


1U4Bbftf 


Me rnarche pas avec java l.h.U 


" 21)04-1 0-U 06:32 


6 templth /" 


hlem 


9140M 


Applique, - transfhrmaNnn nenistrfi quanrt le champ est vide 


* 21)04-03-11 03:04 


5 , Bmpt th/ temptt,/ 


SSSuvU 

B75361 


Probleme sur la recherche chronologjque de personnes 
Perform a nice de la requete de recherche de communes 


* 2004-02-16 05:30 
•2004-01-12 02:29 


5 templth/- templth/. 
5 templth / templth / 


866653 


Affichage ficher personne apres rechargement liste personnes 


'2083-12-28 05:59 


5 templth r 


templth/ 


866652 


Chargement de la liste des personnes sur un patronyme precis * 2D&3-12-28 05:58 


5 templth -^ 


templth/ 


S55402 


Icones pas bonnes 


* 2003-1246 09:22 




templth/ 


852059 


Problem e de performance sous Postgresq] ( manages ) 


* 2003-124)1 05:22 


7 templth/ 


templth/ 


852057 


Affichage des arbres sous Linux 


" 2003-1241 05:19 


7 templth/' 


templth/ 


831792 


creation d?une archive sans adresse 


* 2003-10-28 08:27 


5 templth /• 


leroux-00713 


740518 


Apparence de la barre d'icones 


" 2003-05-20 08:16 


5 templth / " 


templth/ J 


740515 


Enregistrement des dependences de documents 


* 2003-05-20 08:13 


5 templth / 


templth/ 


556253 


Eritiiii Ue mist] ajuu-i de Taibuietjcernje 


•2002-05-15 01:57 


5 templth / 


templth/ 3 " 


542957 


JAVA HOME code en dur dans les .sh 


* 2002-04-12 05:01 


5 templth/ 


nepol 


542953 


JAVAHOME code en dur dans Jes .bat 


' 2002-04-12 04:57 


5 templth / - 


nepol 


* Denotes Re 
Priority Coll 


quests 30 Days Old 
ms: 








1234567 


II 





Figure 10.1 

Consultation des anomalies dans le gestionnaire 

Vous constatez que peu d' anomalies concernent la partie metier de JGenea Ihm : 

• anomalie n° 830964 : recherche de personne ; 

• anomalie n° 830962 : recherche de commune ; 

• anomalie n° 867302 : erreur SQL getListeFreresSoeurs ; 

• anomalie n° 862815 : une seule personne dans un arbre descendant ; 

• anomalie n° 852145 : probleme sur les conjoints dans l'arbre ; 

• anomalie n° 842004 : recherche de personne (chronologique). 



Remarque 

Dans les fiches d'anomalie, aucune indication n'est donnee sur la nature de la correction. Or ces indica- 
tions sont tres precieuses pour evaluer I'impact du correctif sur le logiciel. 
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Vu le faible nombre d' anomalies, vous ne pouvez malheureusement pas detecter a cette 
etape de zones particulierement critiques a analyser dans le cadre du refactoring. 

Statistiques du referentiel CVS 

Les statistiques du referentiel CVS vont vous donner des indicateurs sur le nombre et le 
poids des changements au sein du code de JGenea Web. Ces informations vous permettront 
d'identifier d'eventuels points sensibles a analyser plus precisement. 

Calcul des statistiques 

Pour recuperer les statistiques du referentiel CVS, il est necessaire de disposer d'un 
client CVS permettant d'executer la commande log et d'enregistrer son resultat dans un 
fichier texte. II est recommande d'utiliser le client CVS en ligne de commande. Ce 
dernier est generalement fourni en standard sous UNIX. Sous Windows, il est necessaire 
de le telecharger sur le Web (voir en annexe). 

Les actions suivantes necessitent l'utilisation d'un shell sous UNIX ou de l'invite de 
commandes sous Windows, accessible via Demarrer, Tous les programmes et Accessoires. 

La premiere etape consiste a se connecter au referentiel CVS. Pour cela, il faut definir 
une variable d'environnement, appelee CVSROOT. Sous UNIX (avec un shell bash), il suffit 
de lancer la commande suivante : 

export CVSR00T= :pserver:anonymous@cvs . sour ceforge. net :/cvs root /jgenea 

Sous Windows, la commande est la suivante : 

set CVSROOT=:pserver:anonymous@cvs.sourceforge. net :/cvs root /jgenea 



Important 

Si vous etes derriere un pare-feu empechant l'utilisation du port 2401 , vous devez remplacer dans les 
commandes ci-dessus cvs.sourceforge.net par cvs-pserver.sf.net:80. 



Vous vous connectez ensuite au referentiel CVS par le biais de la commande suivante : 

cvs login 

L execution de la commande cvs login demande un mot de passe. Celui-ci n'existant pas, 
il suffit de presser la touche Entree. Si un message d'erreur apparait, ignorez-le. 

La seconde etape consiste a faire un check-out du module CVS jgenea-web, et non 
jgenea-refactoring, ce dernier ne contenant pas l'historique de son module originel 
jgenea-web. 

Pour cela, il est necessaire de vous positionner dans le repertoire de voire choix, un repertoire 
temporaire, par exemple, et d'executer la commande suivante : 

cvs checkout jgenea-web 
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Une fois la recuperation du module terminee, vous devez generer un fichier de log a 
partir duquel seront calculees les statistiques : 

cvs log > jgenea-web.log 

Pour finir, vous creez un sous -repertoire stats dans lequel StatCVS produira les statistiques 
sur le module jgenea-web : 

Imkdir stats 
cd stats 

Sous UNIX, lancez la commande suivante, en remplacant <repinstall> par le chemin 
vers le repertoire dans lequel est installe statcvs.jar : 

Java -jar <repinstall>/statcvs. jar ../jgenea-web.log .. 

Sous Windows : 

J Java -jar <repinstall>\statcvs. jar ..\jgenea-web.log .. 

Analyse des statistiques 

Une fois la production des statistiques terminee, vous pouvez ouvrir le fichier indcx.html, 
qui vous permet d'acceder a l'ensemble du rapport realise par StatCVS. 

Si vous cliquez sur le lien Directory Sizes, vous pouvez visualiser le tableau illustre a la 
figure 10.2. 



Directory 


Changes 


Lines of Code 


Lines per Change 


Iqenea-web/src/classes/orq /Iqenea /web/ 


143 (39.5%) 


15293 (26.1%) 


106.9 


i q en e a- we b/ s re/ resso U rce s / taqlib/ 


7 (1.9%) 


14096 (24.1%) 


2013.7 


iqenea- web/sre/isp/ 


73 (20.2%) 


13622 (23.3%) 


186.6 


iqenea- web/src/classes/orq/fqenea/eibs/sessions/qenealoqie/ 


19 (5.2%) 
33 (9.1%) 


8452 (14.4%) 
3391 (5.fi%) 


444.8 


iq**nea-wph/«;rr/nlas«;p<;/nrq/inpnea/iitlls/ 


99.7 


iqenea- web/src/classes/orq/iqenea/eibs/entites/personne/ 


3 (0.8%) 
9 (2.5%) 


955 (1.6%) 
736 (1.3%) 


318.3 


iqen ea- web/src / ress o u rces /xmi/ 


81.7 


iqen ca-web/src/classcs/orq /iqenea /cibs/cntites/mariaqc/ 


3 (0.8%) 


471 (0.8%) 


157.0 


iqenea- web/src/classes/orq/iqenea/consanquinite/ 


9 (2.5%) 


467 (0.8%) 


51.8 


iqenea- web/src/classes/orq/iqenea/arbre/ 


10 (2.8%) 


424 (0.7%) 


42.4 


iq e ned - web/sru/resiuu rces/ prop«rli ei / 


10 (2.8%) 


392 (0.7%) 


39.2 


iqen ea- web/ sre/dasses/orq /iqenea /loq/ 


1 (0.3%) 


191 (0.3%) 


191.0 


iqenea- web/build/ 


1 (0.3%) 


162 (0.3%) 


162.0 


iqenea- web/sre/ressources/imaqes/ 


25 (6.9%) 


10 (0.0%) 


0.4 


iqenea- web/src/lib/ 


16 (4.4%) 


(0.0%) 


0.0 


Totals 


362 [100.0%) 


58567 (100.0%) 


161.7 



Figure 10.2 

Statistiques sur les repertoires de JGenea Web 



Les repertoires jgenea-web/sre/ressources/*, jgenea-web/sre/lib et jgenea-web/build 

sont volontairement ignores, car ils ne contiennent pas de code. 



Etude de cas 

Partie III 



Vous pouvez constater que l'essentiel des changements s'est effectue dans les repertoires 
contenant les elements Struts (jgenea-web/src/classes/org/jgenea/web), les pages JSP 
(jgenea-web/src/jsp) et les classes utilitaires (jgenea-web/src/classes/org/jgenea/utils). 
Le nombre de lignes par changement est faible compare au nombre total de lignes. 

Par contre, vous pouvez constater que le repertoire jgenea-web/src/classes/org/jgenea/ 
ejbs/sessions/genealogie contenant 5 fichiers a subi 19 modifications importantes, en 
moyenne 5 % de sa taille totale par changement. 

Le repertoire jgenea-web/src/classes/org/jgenea/ejbs/entites/personne a subi d' encore 
plus gros changements, avec un tiers de son code source en moyenne par changement. 

Le repertoire jgenea-web/src/classes/org/jgenea/consanguinite, qui ne contient qu'un 
seul fichier, a subi proportionnellement beaucoup de changements avec plus de 10 % de 
son code source impacte. 

Revenez a index.html, puis cliquez sur le lien File Sizes and File Counts et consultez la 
rubrique Files with Most Revisions. Le tableau illustre a la figure 10.3 s'affiche. 



= iles with Most Revisions 



File 



D jgenea- web /src/ classes/ 'or g/ jgenea /con sang uinite/ConsanguiniteCalculator.java 

□ jgenea-web/src/classes/org/jgenea/ejbs/sessions/genealogie/GenealogieBean.java 

U jgenea- web/ src/re&sources/xml/struts-config-xnil 

D jgenea- web/src/classes/org/jgenea/ web /FicheActe Action. Java 

Q jgen ea - web/src/ c I a s s e s / o r g / j g e n e a / w e b / A cc u e i I Act i o n . j a v a 

U jgcn ca -web/src/ cla s scs/org /jg c n ca /web / Fich ePc rson n e Action .Java 

L jgenea-web/src/classes/org/jgenea/web/FicheTab!e Action. Java 

D jgenea- web/ s re/ class es/ org /jgen ea / web/ Rech erch er ActesAction Java 

U jgen eo - web/src/ do s ses/org / jgeneo /web/ FicheDocume ntAction .jo va 

Qjgenea-web/src/classes/org/jgenea/web/ListeDocumentsTypeAction.java 

Qjgenea-web/src/classes/org/jgenea/web/Li steTy peDocu mentActio n . j a va 

Jgenea- web/src/ classes /org /Jgenea /web/ n che VI He Action. Java 

D igenea -web/src/classes/ or q/iqenea/ web/ Re chercher Per so nn e sCh ronologique Action. iava 

D jgenea- web/src/]sp/fiche_table.jsp 

Q J g e n e a - we b / s re / cl a s s e s / o rg / J g e n e a / we b / F i c h e D o c u m e n t L i s t e A ct t o n . j a v a 

Q jgenea- web/src/ jsp/fiche_persorine.jsp 

J j g e n e a - w e b / s re/ cl ass es/ o rg / j gen ea / w eb/ Arbre Ascen d a n tPerso n n e Actio n Java 

jgenea- web/src/ classes/org/jgenea/web/RecbercberTablesAction Java 

Ujgenea-web/src/cIassQK/org /jgenea /web/ RechercherDocu nients Action Java 

D jg e nea - web /src/cla sses/org /jgenea / we b / Re c li e re h e r V i 1 1 e s A cte s Ac t i o n Java 



Changes 



Figure 10.3 

Fichiers les plus modifies 



Si vous recoupez ces resultats avec 1' analyse precedente, vous pouvez constater que 
JGenea Web comprend notamment deux classes critiques en terme de changements : 

• ConsanguiniteCal dilator, du package org.geneal ogie.consanguinite ; 

• GenealogieBean, du package org.genealogie.ejbs.sessions.genealogie. 
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Metriques logicielles 

Pour terminer votre analyse quantitative de JGenea Web, vous allez calculer diverses 
metriques logicielles grace au plug-in Eclipse Metrics. 

Calcul des metriques logicielles 

Pour demarrer le calcul des metriques logicielles pour le projet Eclipse jgenea-refactoring, 
il est necessaire de modifier les proprietes de ce dernier via le menu contextuel Properties. 
Cliquez sur la rubrique Metrics dans la partie gauche de la fenetre, puis cochez la case 
Enable Metrics et cliquez sur le bouton OK, comme illustre a la figure 10.4. 

Figure 10.4 

Activation du calcul des 
metriques logicielles 



Properti es f o r j g e n. e a - rsf a ctori ng | □ X | 
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Project References 
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{Metrics 


F" Enable Metrics 
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OK 


cancel 









Pour visualiser les metriques, il est necessaire d'ouvrir la vue correspondante via 
Window, Show View et Other et de selectionner la vue Metrics View dans le repertoire 
Metrics (voir figure 10.5). 



Figure 10.5 

Affichage de la vue Metrics 
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Le calcul des metriques n'est lance qu'au moment de la compilation du projet. II est done 
necessaire d'en lancer une pour les obtenir. Si la compilation automatique est activee, il 
suffit d'operer une reinitialisation via Project et Clean et de selectionner jgenea-refactoring. 
Sinon, il suffit de faire une compilation complete via Project et Build Project. 

Le resultat obtenu pour le projet jgenea-refactoring est illustre a la figure 10.6 (pour le 
voir cliquez sur le projet jgenea-refactoring dans la vue Package Explorer). 



Prnhlpims lavarinr Dprfaratinn Cnnmtp ^ ^fl^> 


» in ■ t5 


n " ° ^ 


MeLfiLb- jytiitid-rerdtLuMiiy 




Metric 


Totnl 


Mcan| 


Std. Dcv. | 


Maximum 


l±l Lines of Code (avg/max per method) 


11499 


16,38 


38,148 


443 


EE Number of Static Methods (avg/max ... 
S Afferent Coupfrig (avg/max per packa... 


10 


0,128 
11,75 


0,822 
14,016 


7 

33 


S Normalized Distance (avg/max per pa... 




0,503 


0,363 


0,971 


1 Number of Classes (avg/max per pack.,. 


70 


9,75 


12,300 


30 


EE SpeuidLdUuuLnJex (dvy/inax per type) 




0,086 


0,206 


1 


l±J Instabity (avg/max per packageFrag... 




0,5 


0,368 


1 


EE Number of Attributes (avq/max per ty... 


282 


3,615 


5,996 


44 


EE Number of Packages 


B 








EE Weighted methods per Class (avg/ma... 


3324 


42,615 


104,182 


895 


Ul Number of Overridden Methods (avg/... 


20 


0,359 


0,700 


3 


EE Number of static Attributes (avg/max ... 


27 


0,346 


1,319 


9 


l±l Nested Stock Depth (avg/max per me... 




1,707 


1,249 


12 


EE Number of Methods (avq/max per type) 

[+1 1 ines of Code (avg/max per type) 


692 
11499 


8,872 


12,99 


80 


147,473 


408,78R 


3470 


EE Lack of Cohesion of Methods (avg/ma... 




□ 


n 


0,967 


Ul McCabe CydomaGc Complexity (avg/... 




4,735 


10,490 


134 


EE Number of Parameters (avg/max per ... 




1,056 


1,641 


22 


EE Abstractness (avg/max per packageFr... 




0,003 


0,009 


0,026 


EE Number of Interfaces (avq/max per p... 













FF Ffferent Coupfrig (avg/max per parka... 


7,1 75 


17,179 


39 


EE Number of Chid nen (avg/max per type) 
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0,308 


2,7 


2-1 


EE Depth of Inheritance Tree (avg/max p... 




1,072 


0,939 
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Figure 10.6 

Metriques de JGenea Web 



Le bouton JJ permet de visualiser les dependances cy cliques au sein du projet. II n'y en 
a pas dans JGenea Web. 

Les lignes en rouge (gris sur la figure) indiquent la presence de valeurs excessives par 
rapport a la norme. Les bornes pour chaque metrique sont definissables en selectionnant 
Metrics Preferences et Safe ranges dans les preferences d'Eclipse (Window\Preferences). 

La signification des colonnes est la suivante : Total additionne les metriques pour 
P ensemble du projet, Mean indique la moyenne, Std. Dev. fournit l'ecart type et Maximum 
donne la plus grande valeur rencontree pour la metrique. 

Pour avoir le detail des metriques, package par package, classe par classe et methode par 
methode, il suffit de cliquer sur le symbole H . 
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Analyse des metriques logicielles 



Vous pouvez constater grace au plug-in Metrics que les metriques suivantes sont proble- 
matiques pour JGenea Web : 

• nombre de lignes de code, que ce soit par methode, comme a la rubrique Lines of Code 
(avg/max per method), ou par classe, comme a la rubrique Lines of Code (avg/max per 
type) ; 

• profondeur d'imbrication des blocs de code, comme a la rubrique Nested Block Depth 
(avg/max per method) ; 

• complexite cyclomatique, comme a la rubrique McCabe Cyclomatic Complexity (avg/ 
max per method) ; 

• nombre de parametres par methode, comme a la rubrique Number of Parameters (avg/ 
max per method). 

Nombre de lignes de code 

Concernant le nombre de lignes par classe, seule la classe GenealogieBean du package 
org. genealogie.ejbs. sessions, genealogie pose probleme. Cette classe compte 
3 470 lignes sur les 5 303 du package, qui contient quatre autres classes. 

Concernant le nombre de lignes par methode, tous les packages de JGenea Web hormis 
org.genealogie.log contiennent des methodes trop longues. Le package le plus critique est 
org. genealogie.ejbs. sessions. genealogie, fortement penalise par GenealogieBean (447 lignes 
pour la plus grosse methode) mais aussi par ses autres classes, hormis FamillesBean, qui 
contiennent des methodes trop longues (entre 87 et 160 lignes). 

Le package org. genealogie. web comprend lui aussi de nombreuses classes (plus de la 
moitie) contenant une unique methode trop importante (entre 55 et 240 lignes) puisque la 
taille de cette derniere est proche du nombre total de lignes pour la classe en question. 
II s'agit generalement de la methode performTask. 

Les autres packages ne contiennent chacun qu'une seule classe problematique : 

• PersonneBean du package org. genealogie. ejbs.entites.personne (202 lignes pour la 
methode la plus grosse sur un total de 614). Cette methode trop longue est ejbStore. 
Comme elle n'est pas utilisee par JGenea Web, vous l'ecarterez de l'etude. 

• ChargementArbre du package org. genealogie. arbre (54 lignes sur un total de 82). 

• Consanguini teCal cul ator du package org. genealogie. consanguinite (51 lignes sur un 
total de 146). 

Profondeur d'imbrication des blocs de code 

Un nombre limite de classes rencontre un probleme de profondeur d'imbrication des 
blocs de code au niveau de leurs methodes. 
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La classe GenealogieBean du package org. genealogie.ejbs. sessions. genealogie comporte 
deux methodes, s'appelant toutes deux getResultatsRecherche, ayant sept niveaux 
d' imbrication. 

La classe ChargementArbredu package org.genealogie.arbre comporte une methode appelee 
chargerGraphics ayant six niveaux d' imbrication. 

Enfin, le package org. genealogie. web comporte neuf classes ayant des methodes avec 
entre six et douze niveaux d'imbrication. La plus problematique est la classe Arbre- 
DescendantPersonneAction, qui comporte les methodes performTask, avec douze niveaux 
d'imbrication, et f 1 1 trerArbre, avec sept niveaux. Les autres classes incriminees compor- 
tent toute une methode performTask (heritee de la classe CheckAction) avec six niveaux 
d'imbrication. 

Complexite cyclomatique 

Un grand nombre de classes de JGenea Web ont une complexite cyclomatique trop 
importante et se trouvent dans la plupart des packages du logiciel. 

La quasi-totalite des classes du package org. genealogie.ejbs. sessions. genealogie est 
concernee. Les extremes sont atteints dans la classe GenealogieBean, avec une 
complexite cyclomatique moyenne par methode de 13,358, dont une atteignant 134 
(getResul tatsRecherche, a l'instar de la profondeur d'imbrication des blocs de code). Les 
autres classes contiennent des methodes complexes mais dans une moindre mesure. 
Notez que TablesRegistresBean possede une methode d'une complexite cyclomatique de 
48 et que DocumentsBean en possede une de 24. 

Le package org. genealogie. web concentre la majorite des classes complexes (27 concer- 
nees), avec des complexity's cyclomatiques moyennes allant de 1 a 38,5. Les trois classes 
les plus touchees sont les suivantes : 

• RechercherldsPersonnesConsanguiniteAction (complexite moyenne de 38,5 avec un 
maximum de 72) ; 

• RechercherPersonnesChronologiqueAction (complexite moyenne de 36,5 avec un 
maximum de 68) ; 

• ArbreDescendantPersonneAction (complexite moyenne de 17,667 avec un maximum 
de 52). 

Ces hauts niveaux de complexite sont systematiquement rencontres au sein de la meme 
methode performTask heritee de la classe CheckAction. Pour ArbreDescendantPersonneAction, 
cela confirme le resultat obtenu avec la profondeur d'imbrication des blocs de code. 

Le package org. genealogie. ejbs.entites.personne comporte une classe PersonneBean ayant 
une methode ejbStore tres complexe. Cette methode n'etant pas utilisee par JGenea Web, 
vous l'ecarterez de l'etude. 

La classe ChargementArbre du package org.genealogie.arbre comporte une methode 
complexe, chargerGraphics, ce qui confirme l'indication fournie par la profondeur 
d'imbrication des blocs de code. 
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Enfin, l'unique classe ConsanguiniteCalculator du package org.genealogie.consanguinite 
possede dans l'absolu une complexite importante pour l'une de ses methodes (15), mais 
qui est relativement normale comparee au reste du logiciel. 

Nombre de parametres par methode 

Plusieurs classes possedent des methodes ayant un trap grand nombre de parametres. La 
plupart d'entre elles sont concentrees dans le package org.genealogie.utils. Si vous 
regardez dans le detail, vous constatez qu'il s'agit de constructeurs pour des JavaBeans 
comportant un grand nombre de proprietes (jusqu'a 22 attributs, se traduisant par autant 
de parametres du constructeur). 

Les autres classes de JGenea Web incriminees comportent entre 6 et 7 parametres, ce qui 
est important sans etre alarmant. 



En resume 



Suite a l'analyse de ces resultats, vous pouvez conclure qu'une attention particuliere doit 
etre portee aux packages org. genealogie.ejbs. session, org.genealogie.arbre, org.genea- 
logie.consanguinite et org.genealogie.web, dont les classes suivantes devront etre analy- 
sees en profondeur (voir section suivante) : 

Geneal ogieBean 

TablesRegistresBean 

DocumentsBean 

ChargementArbre 

Consanguini teCal cul a tor 

RechercherldsPersonnesConsanguiniteAction 

RechercherPersonnesChronologiqueAction 

ArbreDescendantPersonneAction 



Analyse qualitative 

Pour effectuer l'analyse quantitative, vous vous reposerez sur une revue de code avec 
PMD ainsi que sur une revue de conception. 

Revue de code 

Avant d'utiliser PMD pour auditer le code source de JGenea Web, vous devez vous inte- 
resser aux avertissements emis lors de la compilation du projet. 

Analyse des avertissements de compilation 

Ces avertissements sont visualisables dans la vue Problems illustree a la figure 10.7, 
accessible via Window, Show view et Problems. 
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Figure 10.7 

Avertissements emis lors de la compilation 

Pour afficher tous les problemes en une seule fois, il est necessaire de modifier les para- 
metres de filtrage, accessibles en cliquant sur le bouton =t- . 

En consultant la liste des avertissements, vous constatez qu'ils sont de deux natures : 

• Importation de packages non utilises dans le code, impliquant des dependances indues. 
Le simple fait de declarer un import genere automatiquement une dependance pouvant 
entrainer ulterieurement des erreurs si le package ou la classe importee disparait. 

• Utilisation de methodes ou de classes obsoletes, essentiellement des elements du 
framework Struts. Pour assurer une perennite du code, il est necessaire de ne plus 
utiliser ces elements. 



Revue de code avec PMD 

Pour utiliser PMD sur votre projet, il est necessaire de l'activer. Ouvrez pour cela la 
rubrique PMD des proprietes du projet jgenea-refactoring (accessibles via le menu 
contextuel Properties), puis cochez la case Activer PMD ainsi que les regies ayant un 
niveau erreur haute ou erreur (ne les selectionnez pas toutes pour des raisons de perfor- 
mance) et cliquez sur le bouton OK, comme illustre a la figure 10.8. 

Une fenetre vous demande si vous desirez reconstruire le projet. Cette reconstruction 
etant necessaire pour auditer le code, cliquez sur Yes. Armez-vous de patience, car ce 
processus demande generalement plusieurs minutes du fait de la necessite d' auditer 
chaque fichier source. 

Ouvrez la vue Alertes PMD (accessible depuis Window, Show View, Other et PMD). 
Cette vue se presente de la maniere illustree a la figure 10.9. 

Les boutons numerates de 1 a 5 permettent de selectionner les niveaux de priorite des 
anomalies detectees par PMD a afficher dans la vue (1 correspond a une erreur haute, et 
ainsi de suite). 
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Activation de PMD pour le projet jgenea-refactoring 
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Figure 10.9 

La vue Alertes PMD 



Vous pouvez constater qu'il y a 50 anomalies de niveau 1. Celles-ci concernent unique- 
ment des problemes de nommage de variables, comme 1' utilisation du caractere under- 
score (_) ou d'une lettre majuscule comme premiere lettre d'une variable. 
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Les anomalies de niveau 2 sont de differentes natures (pour classer les anomalies par 
regie violee dans la vue, il suffit de cliquer sur l'en-tete de la colonne Regie) : 

• Utilisation combinee de Stri ngBuf f er et de l'operateur +. 

• Utilisation impropre des parametres (reassignation d'une valeur dans le code de la 
mefhode). 

• Utilisation de System . out . pri ntl n. Sur ce dernier point, vous pouvez constater que cette 
utilisation est concentree dans la classe org. genealogie.log. Log. II s'agit done d'une 
fausse alerte. 

Pour completer votre analyse, vous allez activer les regies ayant la priorite Avertissement 
haut. Pour des raisons de performance, dans les proprietes du projet, cochez uniquement 
les regies ayant la priorite Avertissement haut (les autres doivent etre decochees). 

Pour les afficher une fois la reconstruction du projet terminee, assurez-vous que le 
bouton 3 de la vue Alertes PMD est bien enfonce. Les anomalies detectees sont de diffe- 
rentes natures, dont les plus importantes sont les suivantes (celles qui ont deja ete detectees 
lors de 1' analyse quantitative ne sont pas reproduites) : 

• utilisation de l'operateur = dans des conditions ; 

• chaines de caracteres litterales apparaissant plusieurs fois dans le code au lieu d'etre 
centralisees dans une constante ; 

• creation d'objets dans des boucles (pouvant causer des problemes de performance) ; 

• presence de connexions JDBC potentiellement non fermees ; 

• couplage afferent important pour certaines classes ; 

• presence de blocs catch vides ; 

• absence d'accolades dans les conditions ; 

• absence de l'attribut final pour les attributs, les parametres et les variables initialises 
une seule fois ; 

• problemes de nommage : noms trop longs ou trop courts, utilisation de majuscules 
pour des variables ou des constantes non declarees comme telles (e'est-a-dire static 

final) ; 

• utilisation directe des implementations au lieu de l'interface correspondante (par 
exemple, utilisation de java.util .Vector au lieu de java.util .Col lection) ; 

• attributs, variables, parametres et methodes inutilises. 
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Recherche de duplication de code avec PMD 

PMD dispose d'un outil permettant de trouver les duplications de code au sein d'un 
projet. 



Important 

Avant d'executer le detecteur de duplications de PMD, il est necessaire de supprimer le repertoire work de 
votre projet Eclipse s'il existe (pressez la touche F5 dans la vue Package Explorer pour vous en assurer). 
Ce repertoire contient le code Java des pages JSP compilees et brouille la recherche des dupliquas. 



Pour lancer la recherche des dupliquas, ouvrez le menu contextuel du projet jgenea- 
refactoring, et lancez PMD puis Rechercher les copier/coller suspects. La figure 10.10 
illustre les resultats de la recherche de duplication de code. 
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Figure 10.10 

Resultat de la recherche de duplication de code 



Vous pouvez constater qu'il y a un tres grand nombre de duplications de code au sein de 
JGenea Web. Si vous collez le contenu de la fenetre de la figure 10.10 dans un document 
Word vierge, vous obtenez 492 pages avec une police de taille 10 ! 

Ce resultat etant difficilement exploitable du fait de sa taille, vous devez augmenter la 
tolerance du detecteur. Pour cela, vous devez modifier les preferences associees a PMD 
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(dans la rubrique PMD des preferences Eclipse). Dans la sous-rubrique Preferences 
CPD, entrez la valeur 200 dans le champ Taille minimale (il ne s'agit pas de lignes de 
code mais d'elements de code), comme illustre a la figure 10.11. 
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Figure 10.11 

Changement de la tolerance du detecteur de copier/coller 



La trentaine de dupliquas retournes se trouvent tous dans les packages suivants : 

• org.genealogie.ejbs.session.genealogie 

• org.genealogie.ejbs.entites .personne 

• org.genealogie.web 

A une exception pres, les dupliquas sont internes a une classe dans le package org.genea- 
logie.ejbs.session.genealogie. Par contre, vous ne trouvez que des dupliquas entre deux 
classes dans les packages org.genealogie.ejbs.entites. personne et org.genealogie.web (a 
une exception pres). 

Duplications de code internes 

Les duplications de code internes concernent majoritairement le package org.genealo- 
gie.ejbs. session. genealogie et plus particulierement la classe GenealogieBean. Cette 
classe, la plus grosse de tout le projet, avec 3 470 lignes, contient 1 1 dupliquas compris 
entre 18 et 159 lignes. 
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Les autres dupliquas concernent les classes TablesRegistresBean (4 dupliquas compris 
entre31 et38 lignes), DocumentsBean (1 dupliquade 32 lignes) et FamillesBean (1 dupliqua 
de 28 lignes). 

L' unique duplication interne de 34 lignes du package org.genealogie.web conceme la 
classe ArbreDescendantPersonneAction. 

Duplications de code externes 

Les duplications de code extemes concernent majoritairement le package org.genealo- 
gie.web. Celles-ci concernent principalement des actions Struts associees aux riches et 
plus particulierement FicheVilleAction (source de 3 des 6 dupliquas trouves) : 

• FicheActeAction : 54 lignes dupliquees ; 

• FicheTableAction : 38 lignes dupliquees ; 

• FicheDocumentAction : 36 lignes dupliquees. 

Deux autres dupliquas concernant des riches ont comme source FicheDocumentAction : 

• FicheDocumentListeAction : 26 lignes dupliquees ; 

• FicheActeAction : 28 lignes dupliquees. 

Le dupliqua restant qui implique une fiche concerne FicheActeAction et ArbreDescendant- 
PersonneAction (41 lignes dupliquees). 

Deux dupliquas concernent les fonctionnalites de recherche chronologique de personne 
et de determination de consanguinite : 

• RechercherPersonnesChronologiqueAction et RechercherldsPersonnesConsanguiniteAction 
(109 lignes dupliquees) ; 

• RechercherPersonnesChronologiqueForm et RechercherldsPersonnesConsanguiniteForm 
(57 lignes dupliquees). 

La derniere duplication du package implique les classes ArbreDescendantPersonneAction et 
ArbreAscendantPersonneAction (59 lignes dupliquees). 

L' autre cas de duplication externe de JGenea Web detecte concerne les classes Genealo- 
gieBean du package org. genealogie.ejbs. session. genealogie et PersonneBean du package 
org. genea 1 ogie.ejbs. en tites. personne, qui comportent deux dupliquas de 36et42 lignes. 

Complement sur les pages JSP 

Eclipse et PMD ne fournissent pas d'outils pour analyser les pages JSP. Or celles-ci 
representent une part non negligeable de l'application Web qu'est JGenea Web. Vous 
devez done faire la revue de code manuellement. 

Partie HTML des pages JSP 

La partie strictement HTML est simple, du fait de 1' utilisation d'une feuille de style 
(style.css a la racine du projet). Malheureusement, il y a beaucoup de duplication au sein 
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des pages, car elles partagent routes exactement la meme structure. De ce fait, un change - 
ment de cette structure se revele extremement couteux, puisqu'il est necessaire de modi- 
fier toutes les pages. 

Par ailleurs, il faut verifier que le code HTML de JGenea Web est correct. Vous pouvez 
utiliser pour cela le validateur HTML du W3C disponible sur http://validator.w3.org/. Celui-ci 
ne sachant pas interpreter directement les pages JSP, il est necessaire de lancer JGenea 
Web et d'afficher chaque page dans un navigate ur Web pour enregistrer dans un fichier le 
code HTML produit. Ce fichier est alors envoye par formulaire Web au validateur. 

Dans le cas de la page d'accueil, qui s'affiche apres l'authentification, vous avez 58 erreurs 
a corriger. Sachant qu'une grande quantite du code HTML en question est dupliquee 
dans toutes les pages JSP, les corrections ont de fortes chances d'etre fastidieuses. L utili- 
sation de la taglib Tiles de Struts ameliore le rendement en factorisant les parties communes 
des differentes pages. II est aussi interessant de passer les pages en xHTML. Cette evolution 
du HTML standardised par le W3C assure en effet une meilleure compatibilite avec les 
differents navigateurs Web du marc he. 



Remarque 

Le framework Struts possede une taglib HTML destinee a remplacer certains tags HTML dans les pages 
JSP. Elle porte notamment sur les tags pour les formulaires et les liens (la liste est disponible sur http:// 
struts.apache.org/userGuide/struts-html.html). Afin de respecter le fonctionnement de Struts, il est souhai- 
table de les utiliser, ce qui n'est pas systematiquement le cas pour JGenea Web (essentiellement pour le 
tag HTML, les images et les liens). Si vous passez en xHTML, veillez a placer le tag Struts <html : xhtml / 
> en debut de chaque page JSP ou utilisez <html :html xhtml ="true">, qui est equivalent. 



Nous vous invitons a consulter le site Web de la communaute Opquast (http://www.opquast.org), 
qui regroupe les bonnes pratiques pour les services en ligne sur le Web pouvant etre la 
source de refactoring pour 1'IHM. 

Partie Java des pages JSP 

II y a peu de code Java dans les pages JSP de JGenea Web. Le code present concerne 
essentiellement la presentation des informations, ce qui est coherent avec la destination 
des pages JSP, a savoir gerer la partie Vue du design pattern MVC 2. 

Le code Java se presente soit sous forme de tags issus des taglibs Struts bean et 1 ogi c, soit 
sous forme de code Java directement ecrit dans la page. Cette deuxieme forme est parti- 
culierement presente dans les pages JSP chargees d'afficher des listes (liste_*. jsp). Ces 
listes disposent de deux particularites : elles sont paginees, et les couleurs des lignes sont 
alternees, comme illustre a la figure 10.12. 

Le code Java permettant cette presentation est duplique dans chaque page JSP affichant 
des listes, ce qui est prejudiciable en terme de maintenance. II serait interessant de trans- 
former ce code en composant graphique reutilisable en creant une taglib. Vous pouvez 
aussi utiliser des composants tiers, comme ceux proposes dans la taglib Open Source 
Struts-Layout (http://struts.application-servers.com). 
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Figure 10.12 

Presentation d'une liste dans JGenea Web 

Pour terminer, vous pouvez constater que JGenea Web utilise les taglibs Struts bean et 
logic. Ces derniers peuvent etre remplaces avantageusement par la JSTL (JSP Standard 
Tag Library), qui est un veritable standard Java. 



Revue de conception 

Pour clore cette analyse qualitative, vous allez proceder a la revue de conception. Les 
etapes precedentes vous ont permis d' avoir un bon apercu des differents constituants de 
JGenea Web et de leurs faiblesses. La revue de conception a pour objectif de prendre de la 
hauteur par rapport a la masse d' informations accumulee et de definir une ligne directrice 
pour le refactoring. 

Le design pattern MVC 2 est bien mis en oeuvre dans JGenea Web au travers du framework 
Struts. L' analyse des pages JSP n'a pas permis de detecter le travers classique des deve- 
loppements Web, qui consiste a ne pas respecter les couches applicatives et a mettre trop 
d' intelligence dans les pages JSP. La separation entre controleur et modele semble assez 
claire (package org.genealogie.web pour le controleur et package org.genealogie.ejbs.* 
pour le modele). 

Si vous regardez plus en detail la partie controleur, vous constatez que le codage est 
monolithique, surtout au niveau des classes derivant de CheckAction, chacune ayant une 
methode performTask particulierement longue. Par ailleurs, une grande part de la 
complexite de la partie controleur provient des mecanismes de filtrage des donnees en 
fonction des autorisations de l'utilisateur. Idealement, ce filtrage devrait reposer sur les 
mecanismes d' interrogation de la base de donnees pour des raisons de performance. De 
plus, il constitue davantage une problematique du modele puisqu'il s'agit d'une notion 
metier (confidentialite des informations). 
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Pour la partie modele, les classes permettant d'acceder aux donnees de la base conser- 
vent des sequelles de leur passe d'EJB. Ces classes sont dependantes d'une connexion 
JDBC foumie par la partie controleur alors que cette derniere ne l'utilise pas par ailleurs. 
II serait judicieux d'avoir des classes autonomes de la partie controleur pour la gestion 
des connexions JDBC en leur permettant un acces direct au pool. 

L'existence de la classe PersonneBean, heritage du passe, n'est necessaire qu'a cause 
d'une seule autre classe appartenant a la partie Controleur (FichePersonneAction). Vous 
devez done vous interroger sur sa pertinence, d'autant que la classe GenealogieBean 
possede de nombreuses fonctions permettant d'acceder aux informations sur une personne. 
Cette derniere classe, particulierement obese, traite des problematiques liees aux personnes, 
aux actes et aux documents. Une separation de ces trois problematiques permettrait 
certainement d'ameliorer la situation. 

Sachant que JGenea est une solution comprenant deux logiciels, il pourrait etre interes- 
sant de jouer sur les synergies entre eux en mettant en place une architecture orientee 
services. Les fonctionnalites de JGenea Web ne sont jamais qu'un sous-ensemble de 
celles de JGenea Ihm, si vous faites abstraction de la partie IHM. II pourrait done etre 
interessant de mettre en place des services reutilisables au sein du modele plutot qu'un 
simple acces aux donnees de la base au travers d'objets Java. Ainsi, les services de 
JGenea Ihm pourraient etre reutilises tels quels par JGenea Web. Vous pourriez meme 
imaginer que ces services fonctionneraient sur un serveur d' applications et seraient utilises 
en meme temps par JGenea Ihm et JGenea Web. 

Le nommage des composants n'est pas optimal et meriterait d'etre ameliore, notamment 
pour la partie modele, ou le nom des packages, herite du passe, ne correspond pas a la 
nature des classes qu'ils contiennent. En outre, le package org.genealogie.utils contient 
des Beans metier qui devraient en toute logique etre regroupes avec les classes d' acces 
aux donnees. 

En resume 

Pour conclure l'analyse qualitative de JGenea Web, ce logiciel revele les cinq problemes 
suivants : 

• Duplication du code, generant des couts de maintenance inutiles. 

• Complexite et monolithisme du code, rendant la maintenance difficile. 

• Une partie modele perfectible, ne favorisant pas les synergies avec JGenea Ihm. 
L' adoption d'une architecture orientee services permettrait d'implementer jusqu'au 
bout la logique de reutilisation. 

• Perennite du code, du fait de l'utilisation de fonctionnalites de Struts obsoletes, 
compromettant le fonctionnement du logiciel en cas d'upgrade de version de Struts. 

• Lisibilite du code ameliorable, notamment par un nommage approprie et la suppression 
de mauvaises habitudes de codage. 
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Conclusion 



Au chapitre suivant, vous refondrez les parties de JGenea Web qui semblent les plus 
significatives et qui permettent d'illustrer les principales techniques presentees tout au 
long de cet ouvrage. 

A Tissue de ce chapitre, beaucoup de zones a refondre subsisteront, qui vous seront laissees 
a titre d'exercice. 
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Refactoring de JGenea Web 



L' analyse de JGenea Web vous a permis de detecter les points faibles de ce logiciel. Vous 
pouvez done envisager leur refactoring arm d'ameliorer la qualite de JGenea, que ce soit 
en maintenabilite ou en evolutivite. 

Cette refonte a pour objectif d'illustrer la mise en oeuvre des techniques majeures de 
refactoring presentees aux parties I et II de cet ouvrage. 

Le refactoring que vous allez effectuer ici est loin d'etre une refonte exhaustive du logiciel. 
En fin de chapitre, vous verrez d'autres pistes de refactoring a explorer par vous-meme. 

Pour realiser les exercices de ce chapitre, il est necessaire d' avoir installe au prealable le 
plug-in AJDT (voir en annexe pour les procedures d' installation). 



Reorganisation et mise a niveau 

Avant de commencer le veritable refactoring, une correction des avertissements de 
compilation rencontres avec JGenea Web s' impose. Pour rappel, ceux-ci sont de deux 
ordres : dependances inutiles avec des packages (via 1' instruction import) et utilisation 
d' elements Struts obsoletes. 



Reorganisation des imports 

La correction de la premiere sorte de probleme est extremement aisee avec Eclipse puisque 
cet environnement de developpement est dote d'une fonction de reorganisation des imports. 
Dans votre cas, il suffit d'acceder au menu contextuel du repertoire WEB-INF/src et de 
selectionner Source puis Organize Imports, comme illustre a la figure 11.1. 
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Figure 11.1 

Reorganisation des imports 

Si votre projet n'a pas ete recompile automatiquement, il vous faut lancer une recompilation 
complete a partir du menu Project pour que les avertissements disparaissent. 

Grace a cette fonctionnalite, tous les imports inutiles sont supprimes dans l'ensemble du 
code source de JGenea Web, a l'exception des pages JSP, et l'utilisation de * est remplacee 
par des imports donnant explicitement les classes a importer. 

Mise a niveau du code 

JGenea Web utilise des fonctionnalites de la version 1.1 de Struts qui ont ete rendues 
obsoletes dans la version 1.2. Ann d' assurer la perennite du code, il est important de ne plus 
les utiliser, d'autant que ces fonctionnalites sont susceptibles de disparaitre completement 
dans les versions futures de Struts. 

Les problemes rencontres sont generes par l'utilisation de deux classes, org. apache. struts, 
action. ActionError et org. apache. struts .action. ActionErrors. Par ailleurs, JGenea Web 
utilise une version obsolete avec J2SE 1.4.2 de la methode encode de la classe 
Java. net. URLEncoder. 



Mise a niveau de l'utilisation de URLEncoder 

La methode encode utilisee par JGenea Web ne comprend qu'un parametre unique, la chaine 
a encoder. Cette methode doit etre remplacee par encode avec deux parametres, la chaine a 
encoder et le schema d'encodage. Ce dernier, d'apres le W3C, doit obligatoirement etre 
UTF-8 pour le Web. 

La mise a niveau de l'utilisation de URLEncoder passe par la creation d'une interface 
URLEncodingScheme contenant la constante precisant le schema d'encodage en remplacement 
des appels a la methode encode. 
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Le code de URLEncodingScheme est le suivant : 

package org.genealogie.utils; 

public interface URLEncodingScheme { 

final String SCHEME = "UTF-8"; 
} 

Le remplacement des appels se fait simplement en ajoutant dans la liste des imports la 
classe URLEncodingScheme et en utilisant la constante SCHEME comme deuxieme parametre 
de la methode encode de la maniere suivante : 

IChaineEncodee = 
URLEncoder. encode (chaineAEncoder, URLEncodingScheme. SCHEME) ; 

Pour acceder directement au code obsolete, il vous suffit de double-cliquer sur la ligne 
d'avertissement affichee dans la liste de la vue Problems. 

Mise a niveau des elements Struts 

La montee de version de Struts 1.1 a 1 .2 est documented sur le wiki de la communaute 
Apache (http://wiki.apache.org/struts/StrutsilpgradeNotes11to124). Celle-ci s'effectue simplement, 
comme le demontrent les operations presentees ci-apres. 

La classe org. apache. struts. action. ActionError a ete declaree obsolete dans la version 1.2 
de Struts. Elle doit etre remplacee par la classe plus generique, car sachant gerer tout type 
de message, org. apache. struts. action. ActionMessage. 

Pour chaque occurrence d'ActionError, remplacez le code suivant : 

new ActionError( "...") 

par : 

new ActionMessageC . . . ") 

Ce remplacement est notamment necessaire pour utiliser la methode add de la classe 
org. apache. struts. action. ActionErrors (la version de cette methode utilisant ActionError 
est obsolete). 

De la me me maniere, la methode save Errors de la classe org. apache, struts, action. Action 
est obsolete quand elle prend une instance d' ActionErrors en parametre. 

Ainsi, pour chaque instance d' ActionErrors passee en parametre a la methode saveErrors, 
remplacez le code suivant : 

I ActionErrors errors = new ActionErrors( ) ; 
saveErrorstrequest, errors); 
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par : 

IActionMessages errors = new ActionMessagest ) ; 
saveErrors(request, errors); 

Lors de cette derniere mise a niveau, vous pouvez constater que les blocs de code concer- 
ned n'ont en fait aucune utilite (la condition declenchant saveErrors est toujours fausse). 
Vous pouvez done les supprimer sans risque. 

Visualisation des differences avec la version originelle 

Au sein du referentiel CVS, nous avons cree une version contenant le code de JGenea 
Web apres reorganisation des imports et mise a niveau. Grace au client CVS fourni par 
Eclipse ou tout autre client CVS, comme Tortoise CVS, vous pouvez visualiser les diffe- 
rences entre la version ORIGINAL et la nouvelle version, appelee REORG 

Pour cela, il vous suffit d'ouvrir la perspective CVS Repository Exploring et de recher- 
cher la version ORIGINAL dans le referentiel CVS de JGenea. A partir du menu contex- 
tuel de cette version, vous pouvez declencher la comparaison en selectionnant Compare 
With. Une fenetre vous permet alors de selectionner la version REORG, comme illustre 
a la figure 11.2. 



Compare With Branch or Version 



Select a branch or version: 



; | HEAD 

# Branches 
^ ^ Versions 

O REORGPKG 

1§ REORGF IELD 

§ REFACTSTRAT 
f| REFACTG ENDUP 
§ ORIGINAL 
% CORRECSQL 



v 



Refresh from Repository Configure Togs... 



Figure 11.2 

Selection de la version REORG pour comparaison 



Les deux versions sont telechargees a partir du referentiel, et leurs differences sont visua- 
lisables au travers du comparateur d'Eclipse (voir figure 11.3). 
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public class ChargementArbre { 
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Figure 11.3 

Comparaison entre ORIGINAL et REORG 

Test des modifications 

Les modifications que vous avez apportees au code de JGenea Web ne necessitent pas de tests 
particuliers pour detecter d'eventuelles regressions. La reorganisation des imports est neutre 
du point de vue du logiciel. Les elements obsoletes ont ete remplaces par du code simple 
et tres proche de l'original, selon les specifications des concepteurs des API concernees. 

Une simple verification des pages Web dont le code a ete impacte par ces modifications 
suffit, d'autant que leur nombre est faible et qu'une partie du code concerne est inutile. 



Application des techniques de base 

Dans cette section, vous allez utiliser les techniques de base du refactoring pour 

• reorganiser les packages, les classes, les variables et les constantes ; 

• supprimer les dupliquas dans le code. 



Reorganisation des packages et des classes 

Le nom des packages org.genealogie.ejbs.* et org.genealogie.utils n'est pas representatif 
de leur contenu. De meme, les classes qu'ils contiennent ne beneficient pas de regies de 
nommage optimales. 
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Reorganisation des packages org.genealogie.ejbs.* 

Les mentions ejbs, enti tes et sessi ons heritees du passe font penser que ce package contient 
des EJB, ce qui n'est plus le cas. Par ailleurs, dans le sous-package org.genealogie.ejbs. 
sessi ons. genealogie, la mention genealogie apparait deux fois, ce qui est parfaitement 
inutile. Vous allez creer un package unique, org. genealogie. metier, qui regroupera 
l'ensemble des classes des packages org. genealogie. ejbs. entites.personne et org. genea- 
logie. ejbs. sessi ons. genealogie. 

La classe ConsanguiniteCalculator, qui est du metier, devrait se trouver elle aussi dans le 
package org. genealogie. metier. II en va de meme pour les classes du package org. genea- 
logie. arbre. 

Le suffixe Bean employe pour les classes de ces deux packages n'est pas representatif de 
leur fonction, qui est d'acceder aux donnees de la base. Vous le remplacerez par le sufrixe 
DAO pour Data Access Object, plus explicite. 

Pour effectuer ces renommages de packages et de classes ainsi que pour deplacer les clas- 
ses PersonneBean et PersonnePK, vous utiliserez les fonctions d'Eclipse que vous avez vues a 
la partie II. Comme des richiers sont susceptibles d'etre impactes, il sera necessaire de 
selectionner l'option Update fully qualified name in non-Java files (voir figure 11.4). 



Figure 11.4 

Mise en ceuvre de la recherche 
des references dans lesfichiers 
non-Java 



Choose destination for 'PersonneBean. Java': 



(B org.geneabgie.ejbs.entites 

93 org.genealogie.ejbs.enttes.personne 
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ffl org.geneabgie.ejbs.sessions.genealogie 

Hi org.geneabgie.log 

ffl org.geneafogie.utls 

93 org.geneabgie.web 

fi& prapei"tie5 

B-B tests 

E--& WEB-IrJF 

&db 

&img 

&]sp 

p Update references to the moved element(s) 

W update fuly qualfed name n non-Java files (forces preview) 
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Fie name patterns: | *-jsp 

The patterns are separated by commas (* = any string, ? = any character) 
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Dans un premier temps, deplacez PersonneBean et PersonnePK du package org.genealogie. 
ejbs .entites.personne vers org. genealogie.ejbs .sessions. genealogie. Pour cela, selec- 
tionnez une de ces classes dans la vue Package Explorer et choisissez Refactor et Move 
dans le menu contextuel. Dans la fenetre listant les packages de JGenea Web, choisissez 
org. genealogie. ejbs. sessions. genealogie. Recommencez avec l'autre classe. Une fois 
cette operation terminee, vous pouvez supprimer le package org. genealogie. ejbs. 
entites .personne. 

Vous pouvez maintenant renommer le package org. genealogie. ejbs. sessions. genealogie 
en org. genealogie. metier. dao (ajoutez le suffixe dao pour indiquer que ce sous-package 
de org. genealogie. metier ne contient que des DAO). Pour cela, selectionnez le package 
dans la vue Package Explorer, et choisissez Refactor et Rename dans le menu contextuel. 
Selectionnez ensuite chaque classe de ce package dans la vue Package Explorer, et 
renommez-la en remplacant Bean par DAO grace au meme menu contextuel. 

Renommez les packages org.genealogie.consanguinite et org.genealogie.arbre respecti- 
vement org. genea 1 ogie. metier, cons a nguinite et o rg. genea logie. metier, a rbre. 

Reorganisation du package org.genealogie. utils 

Le package org. genealogie. utils contient quatre classes utilitaires (DataBaseLltils, 
RessourcesUtils, El tArbreDescendant et URLEncodingScheme), le reste etant constitue de 
JavaBeans utilises par la partie modele pour transmettre les informations lues en base a la 
partie controleur. Ces JavaBeans n'ont pas vocation a rester dans ce package. lis doivent 
etre integres au sein d'un sous-package de org. genealogie. metier. 

Creez done un package nomme org. genealogie. metier. modele, et deplacez-y les classes 
suffixees par Uti 1 s (sauf les quatre enoncees plus haut) de la meme facon qu'a la section 
precedente. 

Pour finir, le nom de ces classes est suffixe par Uti 1 s, ce qui n'apporte pas d'information sur 
leur nature. Ces classes representant le modele metier de JGenea Web, il est plus judicieux 
de supprimer ce suffixe. Renommez done toutes ces classes (sauf les quatre utilitaires) en 
supprimant le suffixe Uti 1 s. 

Test des modifications 

Bien que les modifications que vous venez d'effectuer soient normalement neutres pour 
JGenea Web, il est interessant de faire fonctionner le logiciel pour vous en assurer. En 
effet, des references cachees a des elements deplaces ou renommes peuvent exister et 
rendre le logiciel inoperant. 

Si vous consultez l'arbre des descendants d'une personne (en allant dans Rechercher des 
patronymes puis en cliquant sur DIDIER, par exemple, puis sur DIDIER Pierre et enfin 
sur le lien Descendants), vous vous apercevez qu'une exception est generee. La raison a 
cela est que le package org. genealogie. metier. modele n'est pas importe dans la page JSP 
arbre_descendant_personne.jsp. Si vous corrigez les imports et les classes renommees 
manuellement, la page fonctionne de nouveau. 
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Vous pouvez done constater que meme les modifications simples peuvent avoir des effets 
de bord mal maitrises du fait des insuffisances de l'outil de refactoring, en l'occurrence la 
mauvaise prise en compte des pages JSP par Eclipse. 

Les modifications que vous avez introduites dans le code sont disponibles dans le refe- 
rentiel CVS dans la version REORGPKG. 

Reorganisation des variables et des constantes 

Comme vous avez pu le constater lors de 1' analyse quantitative avec PMD au chapitre 
precedent, le nommage des variables ne respecte pas scrupuleusement les regies edictees 
par Sun dans ses BluePrints. Par ailleurs, certaines d'entre elles s'averent etre des constantes 
sans pour autant avoir les restrictions d'acces necessaires, en l'occurrence static final. 

Vous ne corrigerez pas ici tous les problemes de nommage rencontres par JGenea Web 
mais vous attacherez a l'attribut NB_PAR_PAGES, qui est duplique a de nombreux endroits 
dans le code et qui s'avere etre une constante. 

Suppression des dupliquas 

Cet attribut present dans 12 classes du package org . geneal ogi e .web a systematiquement la 
meme valeur, a savoir 20. Toutes ces classes heritant de la classe CheckAction, il semble 
judicieux de remonter cet attribut dans la classe mere pour supprimer les dupliquas inutiles. 

Pour effectuer cette operation, il vous suffit d'ouvrir une de classes concernees, par 
exemple Accueil Action, de selectionner par clic droit NB_PAR_PAGES et de choisir Refactor 
et Pull up dans le menu contextuel (voir figure 11.5). 



Figure 11.5 
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dans CheckAction 
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Apres avoir coche NB_PAR_PAGES et clique sur le bouton Next, vous pouvez constater que 
toutes les occurrences de NB_PAR_PAGES sont automatiquement supprimees des classes 
filles de CheckAction. Validez ce refactoring en cliquant sur Finish. 

Transformation en constante 

Malheureusement, NB_PAR_PAGES etant restee pri vate, il est necessaire de le rendre protected 
ou public pour supprimer les erreurs de compilation introduites par le refactoring 
precedent. 

Pour finir, transformez NB_PAR_PAGES en une veritable constante. Pour cela, declarez-la de 
la maniere suivante dans CheckAction : 

protected static final int NB_PAR_PAGES = 20; 

Test des modifications 

Fort de votre experience precedente, effectuez une recherche de NB_PAR_PAGES dans les 
pages JSP (via Search et Files). Vous pouvez constater que cette chaine de caracteres 
n'apparait pas dans les JSP. Le refactoring n'a done normalement pas genere d'effet de 
bord. Pour vous en assurer, vous pouvez executer JGenea Web et consulter quelques 
listes (Recherche de patronymes ou Liste des pays, par exemple). 

Les modifications que vous avez introduites dans le code sont disponibles dans le refe- 
rentiel CVS dans la version REORGFIELD. 



Refonte des classes metier 

Le package org. genealogie. metier. dao (anciennement org.genealogie.ejbs.*) concentre 
a lui seul une grande partie des problemes detectes lors de la phase d' analyse de JGenea 
Web. Dans cette section, vous n'effectuerez pas une refonte complete de ce package mais 
vous concentrerez sur la classe la plus problematique, GenealogieDAO (anciennement 
GenealogieBean), et plus particulierement sur ses methodes getResultatsRecherche. 

Preparation des tests unitaires 

La refonte de Geneal ogi eDAO va modifier son code en profondeur. II est done necessaire de 
creer des tests unitaires pour vous assurer que son comportement est toujours conforme a 
la version originelle. 

Ces tests unitaires concernent les deux methodes getResultatsRecherche, qui sont la cible 
directe de votre refactoring. 

Dans le repertoire tests du projet, creez un package org. genealogie. metier. dao. tests 
contenant le cas de test TestGeneal ogi eDAO, dont le code est reproduit partiellement 
ci-dessous : 
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package org. genealogie.metier.dao. tests; 

import Java. sql .Connection; 

import Java .sql .Dri verManager; 

import Java. util .Vector; 

import junit.framework.TestCase; 

import org.genealogie.metier.dao.GenealogieDAO; 

import o rg. genea logie. metier. model e. Recherche; 

public class TestGenealogieDAO extends TestCase { 
private Connection conn; 
private GenealogieDAO dao; 
private Vector filtre; 

protected void setUpO throws Exception { 

CI a s s. for Name ( "org.hsqldb. jdbcDriver") ; 

conn - Dri verManager. getConnection("jdbc:hsqldb:C:\\Ecl ipseWworkspace 

**\ \ j genea -refactoringWdbWj genea" , "sa" ,"") ; 

dao = new GenealogieDAO(conn) ; 

filtre = new Vector(l) ; 

filtre. add(new Integer(D); 
} 
protected void tearDownO throws Exception { 

conn.close( ) ; 
} 

public void testGetResultatsRecherche( ) { 

Recherche criteres = new RechercheC'dupond" , "yvonne" .false, fal se, false, fal se 

*,false,"trebeurden", "01/01/1716", "01/01/1716"); 

Vector resul tatSansFiltre = dao.getResul tatsRecherche(criteres) ; 

Vector resul tatFiltre = dao.getResul tatsRecherche(criteres, filtre) ; 

assertNotNul 1 ( "Le resultat ne peut etre nul 1 " , resul tatSansFiltre) ; 

assert Equal s("l personne attendue" ,l,resultatSansFiltre.size( ) ) ; 

assertNotNul 1 ( "Le resultat ne peut etre nul 1 " , resul tatFiltre) ; 

assert Equal s("l personne attendue" , 1, resul tatFiltre. si ze( )) ; 

//... 

criteres = new Recherchet "dupond" , "yvonne" .true, true, false, true, true, "","","") ; 

resul tatSansFiltre = dao.getResultatsRecherche(criteres) ; 

resul tatFiltre = dao.getResultatsRecherche(criteres,fil tre) ; 

assertNotNul 1 ( "Le resultat ne peut etre nul 1 " , resul tatSansFiltre) ; 

assert Equal s("l personne attendue" ,l,resultatSansFiltre.size( ) ) ; 

assertNotNul 1 ( "Le resultat ne peut etre nul 1 " , resul tatFiltre) ; 

assert Equal s("l personne attendue" ,1, resul tatFiltre. si ze( ) ) ; 

criteres = new Recherche("dupond", "".true, true, false, true, true, "","","") ; 
resul tatSansFiltre = dao.getResultatsRecherche(criteres) ; 
resul tatFiltre = dao.getResultatsRecherche(criteres,fil tre) ; 
assertNotNul 1 ( "Le resultat ne peut etre nul 1 " , resul tatSansFiltre) ; 
assertEquals("2 personnes attendues" ,2, resul tatSans Filtre. size ( ) ) ; 
assertNotNul 1 ( "Le resultat ne peut etre nul 1 " , resul tatFiltre) ; 
assert Equal s("2 personnes attendues" ,2, resul tatFiltre. si ze( ) ) ; 

//... 
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Pour que ce test fonctionne dans votre environnement, assurez-vous que l'URL de 
connexion JDBC utilisee dans la methode setup contient un chemin correct vers la base 
de donnees. 

Si vous executez ces tests unitaires sur le code originel, une exception est generee (visible 
uniquement dans la console du fait d'un catch effectue dans GenealogieDAO empechant la 
remontee dans JUnit). Les requetes SQL generees par getResul tatsRecherche sont fausses 
parce qu'il manque une virgule dans l'une d'elles et que les clauses FROM sont incorrectes 
pour la table COMMUNE. II vous faut corriger ces erreurs avant le refactoring. 

La version de JGenea Web avec les tests unitaires et les corrections, appelee CORRECSQL, 
est disponible dans le referentiel CVS. Vous devez la recuperer pour poursuivre le refac- 
toring. 

Si vous executez a nouveau les tests unitaires sur cette version, vous constatez que 
l'erreur est corrigee. Pour finir la preparation de la refonte de GenealogieDAO, vous devez 
vous assurer avec EMMA que les tests unitaires couvrent suffisamment de code de la 
classe. 

Pour cela, recompilez tout le projet par securite, et lancez le script Ant build.xml disponible 
a la racine du projet (tache ma i n bull d). 



Important 

Pour que le script fonctionne, il est necessaire de I'executer dans le meme JRE qu'Eclipse (voir la section 
consacree a EMMA au chapitre 5). 



Ce script lance EMMA arm que celui-ci instrumente le code de JGenea Web. Une fois 
1' instrumentation terminee, relancez les tests unitaires pour produire les statistiques de 
couverture. Quand l'execution s'acheve, generez le rapport de couverture en lancant la 
tache report de build.xml (voir le chapitre 9). 

Si vous affichez le rapport coverage.html stocke dans le repertoire coverage du projet 
(rafraichissez la vue Package Explorer en pressant la touche F5 pour le voir), vous obtenez 
un taux de couverture des lignes de code de 88 et 89 % pour les methodes getResul tats- 
Recherche, ce qui devrait etre suffisant pour les operations suivantes. Pour supprimer 
1' instrumentation, il vous suffit de recompiler le projet. 

Suppression des dupliquas 

Le plus gros dupliqua dont est dote GenealogieDAO a une longueur de 159 lignes et 
concerne les methodes getResultatsRecherche(Recherche), a partir de la ligne 2982, et 
getResultatsRecherche(Recherche, Vector), a partir de la ligne 3423. Ces deux methodes 
contiennent plusieurs autres dupliquas importants commencant respectivement aux 
lignes 3178 et 3643 (80 lignes dupliquees) et 3295 et 3784 (73 lignes dupliquees). 
Pour information, ces deux methodes font respectivement 386 lignes et 443 lignes, dont 
312 dupliquees. 
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Si vous analysez le contenu de ces deux methodes, vous constatez que getResultats- 
Recherche(Recherche, Vector) offre la meme fonctionnalite que getResultatsRecherche- 
( Recherche) a un detail pres : elle effectue un filtrage des informations qu'elle renvoie en 
fonction de son deuxieme parametre. 

La methode classique pour supprimer des dupliquas est d'operer une extraction de 
methode. Dans le cas present, vous chercherez plutot a etendre le fonctionnement de 

get Res ultats Recherche (Recherche, Vector) afin qu'elle couvre les besoins de getResultats- 
Recherchet Recherche). 

Vous allez done refondre la premiere puis 1' adapter pour ne garder qu'une seule methode 

get Res ultats Recherche. 

Refonte de getResultatsRecherche(Recherche, Vector) 

La premiere etape de la refonte consiste a extraire du code de getResultatsRecherche de 
maniere a rendre cette methode plus lisible. Commencez par extraire les blocs de code 
generant les requetes SQL. lis sont au nombre de trois. II est recommande de les delimi- 
ter par des commentaires afin de les reperer facilement pour l'extraction. Afin de ne pas 
decaler les numeros de ligne, placez-les a la fin d'une ligne de code existante. En effet, 
des le premier bloc extrait, les numeros de lignes donnes ci-dessous deviennent invalides. 

Le premier bloc court des lignes 3396 a 3511 (determinees sur la version CORRECSQL). 
II commence par les lignes de code suivantes : 

IStringBuffer requete=new StringBuffer( ) ; 
requete. append ( "select personne.personne_id,personne.personne. . . 
requete.append( " from personne personne.l iaison_famille If"); 

et se termine par la ligne : 

requete. append( " order by personne_nom,personne_prenoml") ; 

Le deuxieme bloc court des lignes 3577 a 3640. II commence par les lignes de code 
suivantes : 

IStringBuffer requetel=new StringBuffert); 
requetel.appendC'select personnel. personne_id as mari_id, . . . 
requetel. append (" per sonnel.personne_prenoml as mari_prenom, ") ; 

et se termine par : 

if( !rechercheUtils.getDateFin( ) .equal s("" ) ) { 
requetel. append ( " "+condition+" mariage.mariage_date_ci vi 1 <=?" ) ; 
condition="and" ; 

} 

Le troisieme bloc court des lignes 3717 a 3780. II commence par les lignes de code 
suivantes : 

IStringBuffer requete2=new StringBuffert); 
requete2.append("select personnel. personne_id as... 
requete2. append (" per sonnel.personne_prenoml as mari_prenom, ") ; 
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et se termine par : 

if( ! rechercheUtils.getDateFin( ) .equalsC") ) { 

requete2. append ( " "+condition+"mariage.mariage_date_rel igieux. . . 
condition="and" ; 

} 

Extrayez le premier bloc en le selectionnant par clic droit dans l'editeur et en choisissant 
Refactor et Extract Method dans le menu contextuel. Nommez la nouvelle methode privee 
construitRequeteRecherche. Operez de la meme maniere pour les deux autres blocs, et 
nommez-les respectivement construitRequeteRechercheCivil et construitRequeteRecherche- 
Rel igieux. Pour le deuxieme bloc, la declaration de la variable condition ayant ete 
extraite precedemment, des erreurs de compilation apparaissent. Pour les corriger, il vous 
suffit de la declarer de nouveau en debut de bloc. 

Apres avoir realise cette operation, executez les tests unitaires pour vous assurer que tout 
s'est bien passe, ce qui doit etre effectivement le cas. 

Pour terminer, extrayez les deux blocs construisant le resultat de getResul tatRecherche. 

Le premier bloc court des lignes 3486 a 3537 (apres extraction des trois blocs precedents). 
II commence par les lignes de code suivantes : 

|while( rs.nextO ) { 
Personne mari=new Personnels .getlnt( "mari_id" ) , . . . 
Personne femme=new Personnels. getlnt("femme_id") , . . . 

et englobe toute la boucle whi 1 e. II se termine done a la fin de la boucle. 

Appelez la methode extraite construitResultatRechercheCivil . 

Le deuxieme bloc court des lignes 3563 a 3614. II s'agit la aussi d'une boucle while 
complete a extraire. Elle commence par les memes lignes que le precedent bloc. Appelez 
la methode extraite construitResultatRechercheRel igieux. 

Si vous regardez le contenu de ces deux nouvelles methodes, vous constatez qu'elles 
contiennent deux dupliquas et qu'elles sont identiques. Vous allez d'abord extraire le bloc 
duplique qui apparait le plus en bas dans le code et dont le contenu est le suivant : 

if( ! rechercheUti Is. getNomt ) .equal s("") && ... 

if( femmeNom. equalstrecherchelltils. getNomt ) ) ... 

personnes.addElement(femme) ; 

cles.puttnew Integer (femme. get Id ( )),""); 
} 
} else if( ! rechercheUtils. getNomt ) .equals( "") && ... 
if( femmeNom. equalstrecherchelltils. getNomt ) ) ) { 

personnes. add Element (femme) ; 

cles.puttnew Integer (femme. get Id ( )),""); 
} 
} else if( rechercheUtil s.getNom( ) .equal s( "" ) && ... 

if( femmePrenom.equalstrecherchelltil s.getPrenomt ) ) ) { 

personnes. add Element (femme) ; 

cles.puttnew Integer (femme. get Id ( )),""); 
} 
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} else if( recherchelltil s.getNomt ) .equals( "") && ... 
personnes.addEl ement(femme) ; 
cles.put(new Integer (femme. get Id ( )),""); 
} 

La raison pour laquelle vous devez choisir le dernier bloc duplique apparaissant dans le 
code est que l'assistant d'extraction de methode d'Eclipse ne cherche les dupliquas que 
du point courant jusqu'au debut du fichier. Si des dupliquas sont presents apres le bloc de 
code, il ne les detecte pas. 

Appelez la methode ainsi extraite construitResultatRechercheMF. Vous pouvez utiliser le 
mode previsualisation pour voir les sept dupliquas trouves par Eclipse. 

Pour rinir, vous pouvez remplacer les deux methodes identiques construitResultat- 
RechercheCivil et construitResultatRechercheReligieux par une seule, que vous appellerez 

cons truit Res ul tat Recherche. 

Fusion des deux methodes getResultatsRecherche 

La methode getResultatsRecherche( Recherche) differe de la methode getResultatsRecherche- 
( Recherche, Vector) quant a la construction des requetes SQL. 

Vous devez extraire les blocs correspondants pour en faire des methodes. 

Le premier bloc court de la ligne 2967, apres les extractions precedentes, jusqu'a la 
ligne 3069. II debute par les lignes de code suivantes : 

IStringBuffer requete=new StringBuffer( ) ; 
requete. append ( "select personne.personne_id,personne.personne_noin. . 
requete.append( " from personne personne"); 

et se termine par : 

requete. append( " order by personne_nom,personne_prenoml") ; 

Appelez la methode extraite construitRequeteRechercheSF, avec SF pour sans nitre. 

Le deuxieme bloc court des lignes 3135 a 3176. II debute par les lignes de code 
suivantes : 

IStringBuffer requetel=new StringBuffert ) ; 
requetel.appendC'select personnel. personne_id as mari_id, . . . 
requetel. append (" per sonnel.personne_prenoml as mari_prenom, ") ; 

et se termine par : 

if( !rechercheUtils.getDateFin( ) .equal s("" ) ) { 
requetel. append ( " "+condition+" mariage.mariage_date_ci vil<=?") ; 
condition="and" ; 

} 

Appelez la methode extraite construitRequeteRechercheCivilSF. 
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Le troisieme bloc court des lignes 3216 a 3257. II debute par les lignes de code 
suivantes : 

IStringBuffer requete2=new StringBuffer( ) ; 
requete2.append( "select personnel. personne_id as ... 
requete2.append( "personnel. personne_prenoml as mari_prenom,") ; 

et se termine par : 

if( ! rechercheUtils.getDateFin( ) .equalsC") ) { 

requete2. append (" "+condition+" mariage.mariage_date_rel igieux. . . 
condition="and" ; 

} 

Appelez la methode extraite construitRequeteRechercheReligieuxSF. Pour cette derniere 
methode, il est de nouveau necessaire de declarer la variable condition pour corriger les 
erreurs de compilation. 

Pour terminer la fusion des deux methodes, il vous faut modifier getResultatsRecher- 
che(Recherche, Vector) de maniere qu'elle puisse appeler les methodes de construction 
de requete avec ou sans filtre. La condition evidente pour la selection de la bonne 
methode porte sur la nullite du parametre f ami 1 1 es. S'il est nul 1 , appelez les methodes 
sans filtre, sinon appelez les methodes avec filtre. Remplacez ensuite le corps de la 
methode getResultatsRecherche( Recherche) par un appel unique : 

return getResultatsRecherche(rechercheUtils .null ) ; 

Test des modifications et analyse postrefactoring 

Si vous executez les tests unitaires, vous constatez qu'ils ne detectent aucune regression. 
Par ailleurs, si vous refaites une analyse de couverture avec EMMA (voir la section 
« Preparation des tests unitaires »), vous obtenez un taux de couverture des lignes de 
code pour getResultatsRecherche et ses methodes annexes compris entre 94 et 100 %. 
Grace a la suppression des dupliquas, vous avez done nettement ameliore la couverture 
de votre cas par les tests unitaires. 

Si vous calculez les metriques pour la classe GenealogieDAO, vous constatez qu'elle est 
passee de 3 470 a 3 21 1 lignes. De plus, la profondeur d'imbrication maximale des blocs 
de code est passee de 7 a 5 et la complexite cyclomatique de getResultatsRecherche- 
( Recherche. Vector) de 134a29, faisant passer la complexite cyclomatique moyenne de la 
classe de 13,358 a 10,507. 

Comme vous pouvez le constater, la refonte des deux methodes a contribue a ameliorer 
de maniere notable GenealogieDAO. 

Apres cette refonte des methodes getResultatsRecherche, la version de JGenea Web est 
disponible dans le referentiel CVS sous le nom REFACTGENDUP 
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Utilisation des design patterns 

dans la gestion des acces aux donnees 

Comme indique au chapitre 9, JGenea Web partage son code avec JGenea Ihm, notam- 
ment au niveau des DAO. Les constructeurs de ces DAO necessitent en argument une 
connexion JDBC qu'ils affectent a un attribut prive appele connection. 

Ce mode de fonctionnement est problematique, car le cycle de vie de la connexion n'est 
pas du tout maitrise par le DAO (ouverture ou fermeture), ce qui peut generer des erreurs 
si l'attribut connection contient une connexion invalide. Par ailleurs, comme vous l'avez 
remarque lors de la phase d' analyse, les DAO recoivent leur connexion JDBC des actions 
Struts alors que celles-ci n'en n'ont pas l'utilite directe et rendent leur code plus 
complexe que necessaire. 

Pour ameliorer la separation des preoccupations dans JGenea Web, vous allez gerer le 
cycle de vie des connexions JDBC necessaires aux DAO directement au sein de ces 
derniers, dechargeant ainsi les actions Struts. Les DAO etant destines a fonctionner soit 
en environnement J2EE (JGenea Web), soit en environnement Java/Swing (JGenea Ihm), 
il est necessaire de rendre le processus de creation des connexions adaptable en fonction 
du contexte. Ainsi, pour JGenea Web, vous utiliserez le datasource Struts alors que pour 
JGenea Ihm, vous utiliserez une creation directe de connexion JDBC. 

Pour implementer cette logique de fonctionnement dependant du contexte, vous vous 
reposerez sur le design pattern strategie. Vous aurez de la sorte une strategic Struts et une 
strategie directe pour la creation de connexions JDBC. 

Implementation du design pattern strategie 

Dans un premier temps, definissez l'interface partagee par les deux strategies, 

IJdbcConnectionSel ector : 

package org.genealogie.util s; 

import Java. sql .Connection; 

import Java. sql .SQLException; 

public interface UdbcConnectionSelector { 

Connection getConnection( ) throws SQtException; 
} 

Creez la strategie Struts, StrutsJdbcConnSel ector : 

package org.genealogie.utils; 

import Java. sql .Connection; 
import Java. sql .SQLException; 

import javax.sql .DataSource; 

public class StrutsJdbcConnSelector implements 
UdbcConnectionSelector { 
private DataSource dataSource = null; 
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public StrutsJdbcConnSelector(DataSource pDataSource) 
dataSource = pDataSource; 
} 

public Connection getConnection( ) throws SQLException 
return dataSource. getConnectiont ) ; 



Creez la strategic directe Di rectJdbcConnSel ector : 

package org.genealogie.utils; 

import Java. sql .Connection; 
import Java. sql .DriverManager; 
import Java. sql .SQLException; 

import org.genealogie.log. Log; 

public class DirectJdbcConnSelector implements 
IJdbcConnectionSelector { 
private String url ; 
private String user; 
private String password; 

public Di rectJdbcConnSelector(String pDriver, String pUrl, String 
pUser, String pPwd) { 
url = pUrl ; 
user = pUser; 
password = pPwd; 
try { 

Class.forName(pDriver) ; 
} 

catchtClassNotFoundException e) { 
Log.log(e) ; 

throw new RuntimeException(e) ; 
} 
} 

public Connection getConnection( ) throws SQLException { 
return DriverManager. getConnection(url .user, password) ; 



Pour terminer votre implementation du design pattern, creez la classe singleton, qui 
selectionne la strategie en fonction du contexte : 

package org.genealogie.utils; 

import Java. sql .Connection; 
import Java. sql .SQLException; 

import javax. sql .DataSource; 

import org.genealogie.log. Log; 



Etude de cas 

Parte III 



public class JdbcConnectionSelector implements 
UdbcConnectionSelector { 
public static final int J2EE_DATAS0URCE = 1; 
public static final int JDBC_DIRECT = 2; 

private static JdbcConnectionSelector instance = 

new JdbcConnectionSelector( ) ; 
private UdbcConnectionSelector selector = null; 

private JdbcConnectionSelector( ) { 
} 

public static JdbcConnectionSelector getlnstance( ) { 
return instance; 
} 

public synchronized void setStrategyO'nt pStrategy, 
Object[] pParams) { 
if (selector == nul 1 ) { 
switch (pStrategy) { 
case J2EE_DATAS0URCE: 
selector = 

new StrutsJdbcConnSelector( (DataSource) pParams[0]); 
break; 
case JDBC_DIRECT: 
selector = 
new Di rectJdbcConnSelectort (String) pParams[0] , 
(String) pParams[l], (String) pParams[2] , 
(String) pParams[3]); 
break; 
} 
) 
) 

public Connection getConnection( ) throws SQLException { 
if (selector ™ nul 1 ) { 

Log.logC'Le selectionneur de connexion n'est pas initialise. II faut appeler 

*»la methode setStrategie avant getConnection. " ) ; 

throw new RuntimeExceptiont ) ; 
} 
return selector. getConnection( ) ; 



) 



public boolean islnitial ized( ) 
return (selector != null); 



Remarque 

Pour gerer des implementations de I'interface IjdbcConnectionSelector ayant une liste de parame- 
tres differente, la methode setStrategy comporte comme deuxieme parametre un tableau d'objets 
permettant de s'adapter a tous les cas. 
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Le processus de generalisation de JdbcConnectionSelector dans JGenea Web commence 
par la refonte des DAO. Dans un premier temps, vous allez creer une classe abstraite, 
AbstractDAO, definissant la mecanique de base d'un DAO : 

• gestion du cycle de vie d'une connexion et des elements associes (ResultSet, 

PreparedStatement) ; 

• gestion des exceptions generees par les DAO. 
Le code d'AbstractDAO est le suivant : 

package org.genealogie.metier.dao; 

import Java. sql .Connection; 
import Java. sql .PreparedStatement; 
import Java. sql .ResultSet; 
import Java. sql .SQLException; 

import org.genealogie.utils .JdbcConnectionSelector; 

public abstract class AbstractDAO { 
private Throwable exception = null; 

protected Connection getConnection( ) throws SQLException { 
return JdbcConnectionSelector. get I nstance( ) .getConnection( ) ; 
} 

protected void closeConnectionCConnection pConn.Resul tSet[] 
pRs,PreparedStatement[] pPs) { 
ford'nt i=0;i<pRs.length;i++) { 
try { 

pRs[i ] .close( ) ; 
} 
catch (SQLException e){ 



ford'nt i=0;i<pPs.length;i++) 
try { 

pPs[i ] .close( ) ; 
} 
catch (SQLException e){ 



try { 
if (pConn!=null) { 
pConn. closet ) ; 



catch (SQLException e){ 

} 

forwardExceptiont ) ; 
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protected void setExceptiondhrowable pException) 

exception = pException; 
} 

protected void forwardException( ) { 
if (exception!=nul 1 ) ( 

throw new RuntimeException(exception) ; 

) 



} 

) 

La mecanique de gestion des exceptions implemented ici est tres simple. Lorsqu'une 
exception est generee au sein d'un DAO, elle est stockee dans l'attribut exception via la 
methode setException, apres quoi elle peut etre transferee via la methode forwardException. 

L'interet de proceder de cette maniere est de permettre d'effectuer des traitements de 
nettoyage dans un bloc finally, en l'occurrence la fermeture des ResultSet, PreparedSta- 
tement et Connection, apres la generation de l'exception puis de transferer cette derniere 
de maniere que les couches superieures du logiciel, en l'occurrence les actions Struts, la 
traitent. 



Refonte des DAO 



Vous pouvez maintenant refondre les DAO proprement dits. Avant tout chose, il est 
necessaire de realiser des tests unitaires arm de detecter d'eventuelles regressions apres la 
refonte. Ici, vous vous contenterez des tests unitaires de GenealogieDAO que vous avez crees 
precedemment (normalement, vous devriez avoir des tests unitaires pour chaque DAO). 

Tout d'abord, faites-les tous heriter d'AbstractDAO afin de beneficier de ses services. Vous 
pouvez supprimer la methode getConnection ainsi que l'attribut connection du DAO, car 
ils ne sont plus necessaires. 

Changez ensuite la signature du constructeur afin de supprimer son unique argument. 
Pour cela, vous pouvez utiliser l'assistant de changement de signature de methode fourni 
par Eclipse. Grace a lui, l'ensemble des classes utilisant ce constructeur est automatique- 
ment modifie, ce qui est hautement appreciable pour des classes comme GenealogieDAO, 
qui sont utilisees par beaucoup d'autres classes. 

Pour terminer, vous devez refondre l'ensemble des clauses catch et finally des DAO 
pour integrer votre logique de gestion des exceptions et des connexions. 

Ainsi, le contenu des blocs finally estremplace par un unique appel a la methode close- 
Connection, qui factorise les traitements de fermeture des ressources JDBC et le transfert 
de l'exception potentiellement generee avant le bloc final ly : 

finally { 

ResultSetC] trs = {rs}; 
PreparedStatement[] tps = {ps}; 
closeConnection(conn,trs,tps) ; 

) 
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Le contenu des clauses catch est remplace par un appel a la mefhode setException, qui 
permet au bloc finally de realiser les operations de cloture avant traitement effectif de 
l'exception par les couches appelantes. 

Les rollback sont maintenus dans les clauses catch des methodes DAO effectuant des 
mises a jour de donnees en base : 

catch(SQLException ex) { 

setException(ex) ; 

try { 
conn. rollback( ) ; 

} catchtSQLException exl) {} 
) 



Refonte des actions Struts 

Pour achever votre refactoring, vous devez modifier l'ensemble des actions Struts du 
package org.genealogie.web afin qu'elles ne recuperent plus de connexions JDBC dont 
elles n'ont pas l'utilite. 

Preparation des tests unitaires 

Comme pour les DAO, vous devez mettre en place des tests unitaires pour valider vos 
modifications. Reposez-vous pour cela sur le framework StrutsTestCase derive de JUnit. 
Des tests ont ete definis pour trois classes : LoginAction, qui va subir un refactoring diffe- 
rent des autres actions, Accueil Action et RechercherPersonneChronologiqueAction. 

La classe suivante fournit le test unitaire pour RechercherPersonneChronologiqueAction : 

package org.genealogie.web. tests; 

//Imports. . . 

import servletunit.struts.MockStrutsTestCase; 

public class TestRechercherPersonneChronologiqueAction extends 
MockStrutsTestCase { 

public TestRechercherPersonneChronologiqueAction(String pName) { 
super(pName) ; 
} 

protected void setUpO throws Exception { 
super. setUp( ) ; 

Object[] params = new 0bject[4]; 
params[0] = "org.hsqldb. jdbcDriver" ; 

pa rams [1] = "jdbc:hsqldb:C: WEcl ipseWworkspaceWjgenea-refactoringWdbWjgenea" ; 
params[2] - "sa"; 
params[3] = ""; 
JdbcConnectionSelector.getInstance( ) 

.setStrategy(JdbcConnectionSelector.JDBC_DIRECT,params) ; 
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public void testSuccessful Login( ) { 
Auth auth = new Auth(l,"admin" ,"admin" .true, true, O.nul 

nul 1 ,nul 1 ,nul 1 ,nul 1 ) ; 
getSession( ) . setAttributeCauth" , auth) ; 
DatabaseUtil s. set Id Pool ("Perso" ) ; 

setRequestPathlnfoC/rechercherPersonnesChronologique" 
RechercherPersonnesChronologiqueForm form = 

new RechercherPersonnesChronol ogi queForm( ) ; 
form.setAction( "Create" ) ; 
form.setNomC'") ; 

// Initialisation a "" de chaque attribut de form... 
setActionForm(form) ; 
actionPerform( ) ; 
verifyForwardt "success") ; 

verifyForwardPathC"/jsp/l iste_personnes. jsp") ; 
verifyNoActionErrors( ) ; 
assertNotNul 1 (getRequestt ) . get Attribute ( "result") ) ; 



) 



Important 

Pour que ces tests fonctionnent, il est necessaire de modifier la methode setup afin que I'URL JDBC 
contienne le chemin correct vers la base de donnees. II en va de meme pour le fichier struts-config.xml 
situe dans le repertoire WEB-INF. 



Ce test seul ne marche pas. Du fait du fonctionnement de Struts, la methode reset de 
RechercherPersonnesChronol ogi queForm est appelee lors de l'execution de setActi on, reduisant 
a neant l'initialisation du formulaire que vous realisez dans le test. La classe Rechercher- 
PersonnesChronol ogi queForm etant final, vous ne pouvez pas creer de sous-classe interne 
au test pour redefinir la methode reset. 

Pour ne pas avoir a changer la definition de RechercherPersonnesChronol ogiqueForm, utilisez 
1' aspect suivant (les modalites sont decrites p. 346) : 

package org. geneal ogi e. web. tests; 

import o rg. geneal ogi e. web. RechercherPersonnesChronol ogi que Form; 

public aspect NoFormReset { 

private pointcut aSupprimerO : 
execution (void RechercherPersonnesChronol ogi que Form. reset ( . . ) ) ; 

declare warning : aSupprimerO : 
"Methode supprimee pour permettre les tests unitaires."; 



void around( ) 

) 



aSupprimer( ) 



) 



Si vous executez ces tests unitaires sur le code actuel, vous pouvez constater qu'ils fonc- 
tionnent correctement. 
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Important 

Pour utiliser cet aspect dans Eclipse, vous devez avoir installe prealablement AJDT et avoir declare votre 
projet comme etant un projet Eclipse via son menu contextuel Convert to AspectJ Project. Par ailleurs, 
vous devez vous assurer que la bibliotheque aspectjrt.jar est bien presente dans le repertoire WEB-INR 
lib de votre projet. Si tel n'est pas le cas, vous pourrez la trouver dans le repertoire plugins d'Eclipse. 



Analysez maintenant la couverture de ces tests unitaires avec EMMA. Vous constatez 
qu'ils couvrent moins de 50 % du code des actions Struts concernees. Ce taux doit 
cependant suffire, car les modifications ne doivent pas impacter le fonctionnement des 
actions puisque les connexions JDBC ne sont pas utilisees par celles-ci. 



Remarque 

Vous n'avez plus le taux de couverture par ligne RechercherPersonnesChronologiqueForm a cause 
du compilateur d'AspectJ, qui ne renseigne pas cette information de debogage pour les aspects et les 
classes tissees. Nous avons done du I'exclure de I'instrumentation dans le script Ant afin d'avoir le taux de 
couverture par ligne pour les autres classes de JGenea Web. 



Mise en ceuvre du refactoring 

A l'exception de LoginAction, les blocs similaires a celui presente ci-dessous (avec les 
declarations de variables) sont supprimes purement et simplement des actions Struts de 

org.genealogie.web : 

I dataSource = getDataSource(request,pool ) ; 
conn = dataSource. getConnectiont ) ; 

Par ailleurs, les blocs finally deviennent inutiles (ils sont traites directement dans les 
DAO) et doivent etre supprimes. 

Pour sa part, la classe LoginAction doit etre modifiee, car elle a la charge d'initialiser la 
strategie Struts pour les connexions JDBC (vous avez besoin d'etre dans une action 
Struts pour recuperer la DataSource). 

En lieu et place du bloc de code ci-dessus, vous avez done : 

0bject[] dsParams = new 0bject[l]; 
dsParams[0] = dataSource; 
JdbcConnectionSelector.getInstance( ) 

.setStrategy(JdbcConnectionSelector.J2EE_DATAS0URCE,dsParams) ; 

Enfin, vous devez modifier la clause catch de la methode execute de maniere qu'elle 
accepte le type Exception et non plus SQLException. 

Test des modifications et analyse postrefactoring 

Si vous executez les tests unitaires de TestGenealogieDAO, vous constatez qu' a priori le 
refactoring s'est bien passe. II en va de meme pour les tests unitaires portant sur les 
actions Struts. 
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Par rapport a la version precedente (REFACTGENDUP), vous avez reduit la taille du 
code (2 896 lignes contre 3 211 pour GenealogieDAO) ainsi que la complexite des DAO 
(8,189 contre 10,507 pour GenealogieDAO) etdes actions Struts en factorisant la gestion du 
cycle de vie des connexions JDBC dans une classe abstraite. 

Vous avez de surcroit plus de souplesse pour la reutilisation des DAO en masquant main- 
tenant completement le detail de leur implementation. Enfin, le design pattern strategie 
vous permet de definir des strategies de creation de connexions adaptees au contexte. 
L'emploi d'un pool de connexions pour JGenea Ihm se fera tres simplement en definissant 
une nouvelle implementation de IJdbcConnectionSelector. 

Apres cette refonte des methodes getResultatsRecherche, la version de JGenea Web est 
disponible dans le referentiel CVS sous le nom REFACTSTRAT. 



Modularisation avec un aspect 

Pour achever cette etude de cas, vous allez mettre en oeuvre un aspect factorisant un 
comportement transversal au sein de JGenea Web. Le traitement transversal le plus 
evident est celui qui consiste a verifier si l'utilisateur est authentifie ou non. 

Ce traitement est centralise dans la classe CheckAction, dont heritent toutes les classes 
necessitant, entre autres, cette verification. Par ailleurs, CheckAction fournit plusieurs 
methodes utilitaires qu'utilisent ses descendants. In fine, CheckAction n'a pas vraiment de 
sens d'un point de vue conceptuel et constitue uniquement un moyen d'eviter la duplication 
de code. 

Si vous realisez le controle d'authentification au sein d'un aspect, vous pouvez transfor- 
mer CheckAction en une ou plusieurs classes utilitaires et simplifier l'arbre d'heritage, les 
actions qui necessitent un controle d'authentification n'ayant plus a heriter de CheckAc- 
tion. Leur flexibilite devient ainsi beaucoup plus grande. 

Pour creer cet aspect, choisissez File, New et Other, puis selectionnez l'option Aspect 
dans le dossier AspectJ. Cliquez sur Next. Dans l'assistant de creation qui s'affiche, 
precisez le package, en l'occurrence org.genealogie.web, ainsi que le nom de l'aspect, 
que vous appellerez CheckAuth. 

L aspect est realise de la maniere suivante : 

package org.genealogie.web; 

import j a vax.servlet.http.HttpServlet Request; 
import j a vax.servlet.http.HttpServlet Response; 
import javax.servlet.http.HttpSession; 

import org. apache. st ruts. act ion. Action Form; 
import org. apache. st ruts. acti on. Act ion Forward; 
import org. apache. struts. acti on. Acti onMapping; 
import o rg. genea logie. metier. model e.Auth; 

public aspect CheckAuth { 
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private pointcut checkpoint 

ActionMapping mapping, 
ActionForm form, 
HttpServletRequest request, 
HttpServletResponse response) : 

execution (Action Forward *. execute (ActionMapping, 

Action Form, HttpServletRequest, HttpServletResponse)) 

a rgs( mapping, form, request, response) && 

!within( LoginAction) && 

Iwithin(LogoutAction) ; 

Object around(ActionMapping mapping, ActionForm form, 
HttpServletRequest request, HttpServletResponse response) : 
checkpoint (mapping, form, request, response) { 
if( isAuthentifier(request) ) { 
return proceed (mapping, form, request .response) ; 
} else { 

setNoCachet response) ; 
return mapping. findForward( "login") ; 



private boolean isAuthentifiertHttpServletRequest request) 
HttpSession session=request.getSession( ) ; 
if( session!=nul 1 ) { 

Auth login=(Auth)session.getAttribute( "auth" ) ; 
if( login!=null ) 

return true; 
else 

return false; 
} el se 

return false; 



private void setNoCache(HttpServletResponse response) 
response. set Header ( "Cache-Control " , "no- cache") ; 
response. set Header ( "Pragma" , "no -cache") ; 
response. set Header ( "Expi res" , "0") ; 



Une fois cet aspect en place, supprimez la methode performTask de CheckAction, modifiez 
le contenu de sa methode execute de maniere qu'elle renvoie systematiquement sur la 
page d'accueil, et renommez les methodes performTask de chaque action Struts derivant 
de CheckAction en execute arm que leur traitement soit directement appele par Struts. 

Pour verifier si le refactoring a bien fonctionne, reutilisez les tests unitaires realises 
precedemment avec StrutsTestCase. Vous pourrez par la suite transformer CheckActi on en 
classe utilitaire et liberer completement ses classes derivees de la contrainte de 1' heritage. 
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Grace a cet aspect, il n'est plus obligatoire de deriver de la classe CheckAction pour assurer 
le controle d'authentification. Cette problematique transversale a JGenea est factorisee 
dans l'aspect CheckAuth, ameliorant ainsi la separation des preoccupations. 

La version de JGenea Web apres cette refonte a base de POA est disponible dans le refe- 
rentiel CVS sous le nom REFACTPOA. 



Pour aller plus loin 

Dans cette etude de cas, vous n'avez refondu qu'une petite partie de JGenea Web, et 
beaucoup de zones restent a ameliorer. Le lecteur interesse pourra effectuer les autres 
ameliorations suivantes : 

• Ameliorer Geneal ogi eDAO en extrayant du code vers de nouvelles classes, par exemple, 
un DAO pour les informations geographiques. 

• Fusionner les methodes de Geneal ogi eDAO accedant aux informations sur les personnes 
avec celles de PersonneDAO. 

• Supprimer les dupliquas dans les classes du package org. geneal ogi e. web. 

• Refondre les methodes effectuant des filtrages dans les actions Struts. Ce type d'operation 
doit etre pris en charge par les DAO en se reposant sur des requetes SQL. 

• Utiliser le design pattern interpreteur pour refondre la validation des formulaires (methode 
validate dans les classes derivees d'ActionForm). Pourcela, vous pourrez utiliser l'outil 
Validator fourni par le framework Struts. 

• Refondre JGenea Ihm, de preference une ancienne version. 
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Annexe 



Vous trouverez dans cette annexe les procedures permettant de telecharger et d'installer 
les outils necessaires aux exemples de l'ouvrage et a l'etude de cas. 

Ces outils etant tous issus de la communaute Open Source, ils peuvent etre utilises 
gratuitement sur vos projets. 

La derniere section presente le DDL de 1' application JGenea Web. 



Installation d'Eclipse 



Installation d'Eclipse 

Eclipse peut etre telecharge gratuitement depuis la page Downloads du site Web http:// 
www.eclipse.org. 

L' installation d'Eclipse necessite au prealable la presence d'un JRE (Java Runtime Envi- 
ronment), dont la version est specifiee sur la page de telechargement. 

Eclipse se presente sous la forme d'un fichier Zip a decompresser dans le repertoire de votre 
choix. La decompression cree une arborescence dont le repertoire racine s'appelle eclipse. 

Quand la decompression est terminee, vous pouvez lancer l'executable (eclipse.exe pour 
Windows) present a la racine du repertoire eclipse pour demarrer l'environnement de 
developpement. 

La configuration des preferences d'Eclipse permettant de faire fonctionner les exemples 
et 1' etude de cas est indiquee dans les chapitres en fonction des besoins. 

Installation de PMD sous Eclipse 

Depuis la version 2.2.2v3 du plug-in PMD, son installation sous Eclipse suit une procedure 
standard, de meme que celle des autres plug-in necessaires a l'ouvrage, sauf cas particulier. 

PMD est aussi disponible pour JBuilder, JDeveloper, Netbeans, etc. ainsi qu'en mode 
ligne de commande. Vous pouvez vous reporter au site Web de PMD pour connaitre la 
procedure d' installation dans ces environnements (http://pmd.sourceforge.net). 

1. Avant de demarrer la procedure d'installation, sauvegardez votre travail en cours 
dans Eclipse. 

2. Lancez l'assistant d'installation et de mise a jour d'Eclipse en choisissant Help, 
Software Updates et Find and Install. 



Install/Update 



Feature Updates 
Choose the way you want to search for features to install 




C Search for updates of the currently instaled features 
(• Search for new features to install 



< Back 



Finish 



Cancel 



Figure 1 

Assistant d'installation et de mise a jour d'Eclipse 
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3. Dans la fenetre Feature Updates, activez l'option Search for new features to install, et 
cliquez sur le bouton Next. 

La fenetre qui s'affiche presente la liste des sites publiant des mises a jour des 
produits declares dans votre environnement. Par defaut, la liste ne comprend que le 
site de mise a jour de 1' environnement Eclipse lui-meme. 



Update sites to visit 

Select update sites to visit while looking for new features. 




Sites to include in search: 



El □ "Sjl Ecfpse.org update ste 


New Remote Site... 


New Local Site... 


New Archived Site... 


Edit.. 


Remove 





W Ignore features not applicable to ths environment 



< Qaek Mext > Cancel 



Figure 2 

Listes des sites de mise a jour 



4. Cliquez sur le bouton New Remote Site. 



New Update Site 



Name: j PMD Edpse Site 



URL: | http://pmd.sourceforge.net/eclipse 



Figure 3 

Declaration du site de mise a jour de PMD 



5. Dans le champ Name, specifiez le nom du site de mise a jour en rappelant le nom du 
plug-in correspondant. 



Installation de PMD sous Eclipse 



6. Dans le champ URL, entrez l'URL du site de mise a jour, en l'occurrence http:// 
pmd. sourceforge. net/eclipse. 

7. Cliquez sur le bouton OK. La liste des sites publiant des mises a jour affiche une 
nouvelle entree correspondant a PMD. 

8. Cochez cette nouvelle entree, et cliquez sur Next. 

Eclipse se connecte au site de mise a jour et affiche la liste des elements disponibles 
en telechargement. 



Update sites to visit 

Select update sites to visit while looking for new features. 



6Q 





Sites to include in search: 






El O 'Sfl Edpse.org update ste 


New Remote Site... 1 




New Local Site... 




New Archived Site... 




Edit... 




Remove 







W Ignore features not applicable to this environment 



Figure 4 

Elements disponibles en telechargement 



9. Selectionnez la version la plus recente correspondant a votre version d' Eclipse, ici la 
2.2.2v3, car nous utilisons Eclipse 3, puis cliquez sur Next. 

Une fenetre affiche la licence attachee a PMD. 

10. Selectionnez l'option I accept the terms in the license agreements, et cliquez sur Next. 
Une fenetre recapitule la fonctionnalite que va etre installee. 

11. Cliquez sur Finish pour demarrer l'installation. 

12. Une fenetre de confirmation vous demande si vous voulez installer PMD. Cliquez sur 
Install. 
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13. Une fois le telechargement de PMD acheve, une fenetre vous indique qu'il est neces- 
saire de redemarrer Eclipse pour prendre en compte les modifications. Si vous avez 
sauvegarde votre travail prealablement a l'installation, cliquez sur Yes. Sinon, cliquez 

sur No. 

14. Sauvegardez votre travail, et relancez Eclipse. 

15. Pour verifier que PMD est bien installe, choisissez Help et About Eclipse Platform 
dans la barre de menus d'Eclipse. 

16. Dans la fenetre qui s'affiche, cliquez sur Feature Details. 

Dans la liste qui s'affiche, vous devez voir apparaitre une fonctionnalite (Feature) 
appelee PMD UI Plugin. 



About Eclipse Platform Features 



nixi 



Provider 


| Feature Name 


Version 


Feature Id 


Ectpse.org 


Aspect] Development To... 


1.2.0.20041... 
3.0.2 


org.ectpse.aspectj 




tclpse.org 


tclipse Java Devebpmen... 


org. eclipse jdt 




Eclpse.org 


Eclipse Java Devebpmen... 


3.0.2 


org .ectpse.jdt.sou rce 




Ecfpse.org 


Ectpse Platform 


3.0.2 


org .ectpse. platform 




Ectpse.org 


Ectpse Platform Pluq-in D... 


3.0.2 


orq .eclipse, platform.so jrce 




Ectpse.org 


Eclipse Plug-in Devefopm... 


3.0.2 


org.ectpse.pde 




Friipse.orrj 


FrGpse Plug-In npvelnpm... 


3.0.2 


org.priipsp. prip. m\ irce 




Ectpse.org 


Eclipse Project SDK 


3.0.2 


org.ectpse.sdk 




Frank Sauer 


metrics Plug -in 


1.3.5 


n et.sou rceforge. metrics 




PMD Team 


PMD Ul Pluqin 


2.2.2.V3 




Takuya Yamashita 


Jupiter Review Plug-in 


2.2.326. 3x 


csdl.jupiter 























(c) 1997-2003 PMD Team 



Pluy-in Detdils 



Figure 6 

Verification de l'installation de PMD 



Installation de Checkstyle sous Eclipse 

Les instructions d' installation de Checkstyle sous Eclipse ont ete etablies a partir de la 
version 3.5.0 du plug-in. 

Checkstyle est aussi disponible pour JBuilder, Netbeans, IntelliJ IDEA, etc., ainsi qu'en 
ligne de commande. Vous pouvez vous reporter au site Web de Checkstyle (http://check- 
style.sourceforge.net/) pour connaitre sa procedure d' installation dans ces environnements. 



Installation de Checkstyle sous Eclipse 



1 . Telechargez le fichier Zip contenant le plug-in Checkstyle a l'URL http://eclipse- 
cs.sourceforge.net/. 

Pour la version 3.5.0 de Checkstyle, le fichier est nomme : 
com.atlassw.tools.eclipse.checkstyle_3.5.0-bin.zip. 

2. Si Eclipse est ouvert sur votre ordinateur, fermez-le avant de continuer la procedure. 

3. Decompressez le fichier Zip dans le sous-repertoire plugins du repertoire dans lequel 
est installe Eclipse. 

4. Quand la decompression est terminee, relancez Eclipse pour vous assurer de la bonne 
installation du plug-in. 

5. Pour verifier que le plug-in Checkstyle est bien installe, choisissez Help et About 
Eclipse Platform dans la barre de menus d'Eclipse. 

6. Dans la fenetre qui s'affiche, cliquez sur Plug-in Details. 

Vous devez voir apparaitre la ligne Checkstyle Plug-in dans la colonne Plug-in Name. 



About Eclipse Platform Plug-ins 




OLE 
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Plug in Name 


Version 


Plug in Id 


A 


Apache 


Apache Xerces 


2.6.2 


org.apache.xerces 
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Da', d Schn eider 
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3.S.0 
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Eclipse.org 
Eclipse.org 


Ant Build Tool Core 
Art UI 


3.0.0 
3.0.2 


org.ectpse.ant.core 
org.ectpse.antui 
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1.fi.7 


org.aparhe.ant 


Eclipse.org 


Apache Lucene 


1.4.3 


org.apache.lucene 


Eclpsc.org 


Aspect] 


l.E.0.20041... 


org.ospccrj.ajdc 


Ectpse.org 


Aspect] Development To... 
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org.ectpse.aspectj 
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org.ectpse.update.s 


cheduler 
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Cheat Sheets 
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org .ectpse.compa re 
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Console 
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>urces 
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Edpse.org 


Core Resource Managem... 
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Core Runtime 
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Core Runtime Plug-in Co... 
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time.co... 
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org .ectpse. core, van 


















Mare Info 




OK 











Figure 7 

Verification de la bonne installation de Checkstyle 
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Installation de Metrics sous Eclipse 

La procedure d' installation du plug-in Metrics sous Eclipse etant identique a celle de 
PMD, nous ne la decrivons pas en detail. 

Ces instructions ont ete etablies a partir de la version 1.3.5 du plug-in Metrics. 

1. Lors de la declaration du site de mise a jour (New Remote Site), specifiez l'URL http:/ 
/metrics.sourceforge.net/update. 

2. Pour verifier que Checkstyle est bien installe, choisissez Help et About Eclipse Plat- 
form dans la barre de menus d'Eclipse. 

3. Dans la fenetre qui s'affiche, cliquez sur Feature Details. 
Vous devez voir apparaitre la ligne metrics Plug-in. 



About Eclipse Platform Features 



Provider 



Feature Name 



Version 



Feature Id 



Ectpse.org 
Ectpse.org 
FnSpse.org 
Eclpse.org 
Cctp5e.0rg 
Ectpse.org 
Eclpse.org 
Ectpse.on 



Aspect] Development To.. 

Ectpse Java Devebpmen.. 
Fclipsp lava Devplopmen.. 
Ecfpse Platform 
Ccfpse Platform Plug-in D.. 
Eclipse Plug-in Devetopm... 
Eclpse Plug-in Devebpm... 
Ecfpse Project SDK 



PMD Team 
Takuya Yamashita 



PMD UI Pkjgin 
Jupiter Review Plug-in 



Metrics ptugin for Eclpse 

Version: 1.3.3 

fc) Copyright Frank Sauer and others 2003. 

Vat http://mctrics.30urccforgc.net 



More Info Plug in Details 



1.2.0.20041.. 

3.0.2 

3.0.2 

3.0.2 

3.0.2 

3.0.2 

3.0.2 

3.0.2 

2.2.2.V3 
2.2.328.3X 



org.ectpse.aspectj 

org .eclipse.] dt 

org .pcfipsp.jrit.soi i rrp 

org .eclipse, platform 

org .eclipse, platform.source 

org .eclipse, pde 

org .eclpse. pde. source 

org.eclipse.sdk 

n et.sou rceforge. pmd .ecfpse 
csdljupiter 



Figure 8 

Verification de V installation de Metrics 



Telechargement d'EMMA 



Telechargement d'EMMA 



EMMA est un outil Java telechargeable directement depuis son site Web (http://emma.source- 
forge.net/). 

1 . Depuis le site d'EMMA, cliquez sur le lien Downloads puis sur le lien SourceForge down- 
load page. 

2. Une liste de fichiers vous est proposee. Selectionnez le fichier emma-x.y.z-lib.zip le 
plus recent dans la categorie emma-release (x, y et z sont des numeros de version). 

3. Une liste de sites miroirs de telechargement vous est proposee. Cliquez sur le lien de 
la colonne Download correspondant au miroir le plus proche de chez vous. 

4. Apres quelques instants, le telechargement demarre. Si tel n'estpas le cas, cliquez sur 
un lien, comme indique a l'ecran, ou changez de miroir. 

5. Une fois le fichier Zip telecharge, decompressez-le. 

Ce fichier Zip contient deux fichiers, emma.jar et emma_ant.jar. 

Telechargement du client CVS pour Windows 

Contrairement a Linux, Windows n'est pas dote par defaut d'un client CVS en ligne de 
commande. Le site Web de CVS propose en telechargement un tel client pour le systeme 
d' exploitation de Microsoft (http://www.cvshome.org). 

1. Sur la page d'accueil, cliquez sur CVS downloads. Une liste de repertoires s'affiche. 

2. Cliquez sur le repertoire binaries puis sur le sous-repertoire Win32. Une liste de 
fichiers Zip s'affiche. 

3. Cliquez sur le nom de fichier Zip dont le statut (colonne Status) est Stable (cvs-1-11- 
19.zip au moment de la redaction de cet ouvrage). 

4. Ouvrez le fichier Zip telecharge, et decompressez le fichier cvs.exe dans le repertoire 
de votre choix. 

5. Ajoutez ce repertoire a la variable d'environnement PATH afin qu'il puisse etre 
appele directement depuis n'importe quel autre repertoire. 

6. Pour verifier que le client CVS fonctionne bien, lancez une invite de commande (via 
les menus de Windows Demarrer, Tous les programmes et Accessoires), et entrez cvs. 
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Vous devez obtenir l'affichage suivant 



Usage: cvs [cvs-options] command [command-options-and-arguments] 
where cvs-options are -q, -n, etc. 

(specify --help-options for a list of options) 
where command is add, admin, etc. 

(specify --help-commands for a list of commands 
or --help-synonyms for a list of command synonyms) 
where command-options-and-arguments depend on the specific command 
(specify -H followed by a command name for command-specific help) 
Specify --help to receive this message 
The Concurrent Versions System (CVS) is a tool for version control. 
For CVS updates and additional information, see 
the CVS home page at http://www.cvshome.org/ or 
Pascal Molli's CVS site at http://www.loria.fr/~molli/cvs-index.html 



Telechargement de StatCVS 



StatCVS est un programme Java telechargeable directement depuis son site Web (http:// 
statcvs.sourceforge.net/). 

1. Depuis le site de StatCVS, cliquez sur le lien Download StatCVS. Une liste de sites 
miroirs de telechargement vous est proposee. 

2. Cliquez sur le lien de la colonne Download correspondant au miroir le plus proche de 
chez vous. 

3. Apres quelques instants, le telechargement demarre. Si tel n'est pas le cas, cliquez sur 
un lien comme indique a l'ecran ou changez de miroir. 

4. Une fois le fichier Zip telecharge, decompressez-le. 

Un sous-repertoire statcvs-0.2.2 est cree contenant notamment le fichier statcvs.jar, qui 
est le programme executable Java de StatCVS. 



Telechargement de Tomcat 



Telechargement de Tomcat 



Pour les besoins de l'etude de cas, nous utilisons le moteur de servlets/JSP Tomcat. Son 
programme d' installation est disponible via la rubrique Download et la sous-rubrique 
Binaries, du site Web de Tomcat (http://jakarta.apache.org/tomcat). 

Tomcat necessite 1' installation prealable d'un JDK, dont la version est specifiee dans la 
documentation fournie sur le site Web. Pour Tomcat 5, il s'agit du JDK 1.5. 

L'etude de cas utilise les parametres par defaut proposes par l'assistant d'installation. 

1. Apres avoir installe Tomcat, lancez-le, et verifiez que la page affichee par l'URL http:/ 
/localhost:8080 correspond a la page d'accueil de Tomcat. 

2. Au besoin, remplacez 8080 par le port que vous avez specifie au moment de l'instal- 
lation. 

II ne faut pas oublier d'arreter Tomcat apres ce test pour pouvoir utiliser le plug-in 
Tomcat de Sysdeo. Ce plug-in est utilise pour piloter Tomcat depuis Eclipse. 

Installation et configuration du plug-in Tomcat de Sysdeo 
pour Eclipse 

La procedure d'installation du plug-in Tomcat de Sysdeo pour Eclipse a ete etablie a 
partir de la version 3.0.0 du plug-in. 

1 . Telechargez le fichier Zip du plug-in Tomcat directement sur la page d' accueil du site 
Web dedie (http://www.sysdeo.com/eclipse/tomcatPluginFR.html). 

2. Si Eclipse est ouvert sur votre ordinateur, fermez-le avant de continuer la procedure. 

3. Decompressez le fichier Zip telecharge dans le sous-repertoire phi gins du repertoire 
dans lequel est installe Eclipse. 

4. Quand la decompression est terminee, relancez Eclipse pour vous assurer de la bonne 
installation du plug-in. 

Jrl ^S $1 Si le plug-in Tomcat est bien installe, vous devez voir apparaitre les 
icones ci-contre dans la barre d'outils d'Eclipse. 

5. Avant de configurer le plug-in, il est necessaire d'installer Tomcat (voir ci-dessus). 

6. Dans la barre de menus d'Eclipse, choisissez Window et Preferences. 

7. Dans la boite de dialogue Preferences, selectionnez Tomcat pour acceder aux para- 
metres du plug-in. 

8. Dans la partie droite de la fenetre, reglez les parametres suivants : 

- Version de Tomcat : indiquez la version de Tomcat que vous avez installee. 

- Repertoire de Tomcat : indiquez le repertoire ou vous l'avez installe. 

- Declaration des contextes : activez la case « dans Server.xml ». 
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Figure 9 

Parametres du plug-in Tomcat 

9. Cliquez sur OK. 

10. Afin de verifier le bon fonctionnement du plug-in, assurez-vous que Tomcat n'est pas 
deja lance sur votre machine. 

11. ^ Dans la barre d'outils d'Eclipse, cliquez sur le bouton ci-contre. Dans la vue 
Console, les logs d'execution de Tomcat doivent apparaitre. 

12. Lorsque la ligne « INFO: Jk running » s'affiche, lancez un navigateur Web, et entrez 
l'URL http://localhost:8080.Vous devez voir la page d'accueil de Tomcat s'afficher avec 
le message suivant, indiquant que tout s'est bien deroule : "If you're seeing this page 
via a Web browser, it means you've setup Tomcat successfully. Congratulations!". 

13. £& Pour arreter Tomcat, cliquez sur le bouton ci-contre de la barre d'outils d'Eclipse. 



Installation du plug-in AJDT pour Eclipse 

La procedure d' installation du plug-in pour Eclipse AJDT d' AspectJ (http://www.eclipse.org/ 
ajdt/) a ete etablie a partir de la version 1.2 d'AJDT Etant identique a celle de PMD, nous 
ne la decrirons pas en detail. 



Installation du plug-in AJDT pour Eclipse 



Des plug-in AspectJ pour JBuilder, JDeveloper et Netbeans sont disponibles a la rubrique 
Downloads du site Web d'AspectJ (http://www.eclipse.org/aspectj/). 

1. Lors de la declaration du site de mise a jour (New Remote Site), specifiez l'URL http:/ 
/download.eclipse.org/technology/ajdt/30/update pour Eclipse 3. Ox. 

2. Si vous utilisez Eclipse 3.1, specifiez l'URL http://download.eclipse.org/technology/ajdt/31/ 
update. 

3. Dans la liste des versions disponibles, selectionnez la plus recente (dans cet ouvrage 
nous utilisons la version 1 .2). 

4. Pour verifier qu'AJDT est bien installe, choisissez Help et About Eclipse Platform 
dans la barre de menus d' Eclipse. 

5. Dans la fenetre qui s'affiche, cliquez sur Feature Details. 

Vous devez voir apparaitre dans la colonne Feature Name la ligne AspectJ Development 
Tools. 



About Eclipse Platform Features 
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Version 
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Eclipse.org 

Fclpse.nrg 
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Figure 10 

Verification de V installation d'AJDT 
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Script DDL de JGenea Web 

Le script DDL ci-dessous permet de creer l'ensemble des tables necessaires au fonction- 
nement de 1' application JGenea Web. II a ete mis au point pour le SGBD HSQL. 



Nom de la base : JGENEA 

Nom de SGBD : HSQL 

Date de creation : 05/03/2002 



Table : PAYS 



create table PAYS 
( 

PAYS_ID INTEGER not null, 

PAYS_N0M CHAR(255) not null, 

constraint PK_PAYS primary key (PAYS_ID) 
); 



Table : DEPARTEMENT 



create table DEPARTEMENT 
( 

DEPARTEMENT_ID INTEGER not null, 

DEPARTEMENT_NOM VARCHARC255) not null, 

DEPARTEMENT_NUMERO VARCHAR(5) not null, 

DEPARTEMENT_PAYS_ID INTEGER not null, 

constraint PK_DEPARTEMENT primary key (DEPARTEMENT_ID) , 

constraint departementpaysfk FOREIGN KEY (DEPARTEMENT_PAYS_ID) 

PREFERENCES PAYS ( PAYS_ID) 
); 



Table : COMMUNE 



create table COMMUNE 
( 

COMMUNE_ID INTEGER not null, 

C0MMUNE_N0M VARCHAR(255) not null, 

C0MMUNE_N0M_EQUIVALENT VARCHAR(255) null, 

C0MMUNE_DEPARTEMENT_ID INTEGER not null, 

constraint PK_C0MMUNE primary key (COMMUNE_ID) , 

constraint communedepartementf k FOREIGN KEY (COMMUNE_DEPARTEMENT_ID) 

PREFERENCES DEPARTEMENT(DEPARTEMENT_ID) 
); 



Table : PERSONNE 



Script DDL de JGenea Web 



create table PERSONNE 
( 

PERSONNE_ID INTEGER not null, 

PERS0NNE_N0M CHAR(255) not null, 

PERS0NNE_PREN0M1 CHAROO) not null, 

PERS0NNE_PREN0M2 CHAROO) null, 

PERS0NNE_PREN0M3 CHAROO) null, 

PERSONNE_PARRAIN_ID INTEGER null, 

PERSONNE_MARRAINE_ID INTEGER null, 

PERSONNE_DATE_NAISSANCE DATE null, 

PERSONNE_DATE_NAISSANCE_APP CHAROO) null, 

PERSONNE_COMMUNE_ID_NAISSANCE INTEGER null, 

PERSONNE_DATE_BAPTEME DATE null, 

PERSONNE_DATE_BAPTEME_APP CHAROO) null, 

PERS0NNE_COMMUNE_ID_BAPTEME INTEGER null, 

PERS0NNE_PR0FESSI0N CHARC60) null, 

PERSONNE_DATE_DECES DATE null, 

PERSONNE_DATE_DECES_APP CHAROO) null, 

PERS0NNE_COMMUNE_ID_DECES INTEGER null, 

PERS0NNE_DATE_INHUMATION DATE null, 

PERSONNE_DATE_INHUMATION_APP CHAROO) null, 

PERS0NNE_COMMUNE_ID_INHUMATI0N INTEGER null, 

PERSONNE_PERE_ID INTEGER null, 

PERSONNE_MERE_ID INTEGER null, 

PERSONNE_ENFANT_NATUREL INTEGER not null, 

PERS0NNE_COMMENTAIRES VARCHAR null, 

PERSONNE_ADRESSES VARCHAR null, 

PERSONNEJOMME INTEGER not null, 

constraint PK_PERSONNE primary key (PERSONNE_ID) , 

constraint communebaptemef k FOREIGN KEY (PERSONNE_COMMUNE_ID_BAPTEME) 
PREFERENCES COMMUNE ( COMMUNE_ID) , 

constraint communenaissancefk FOREIGN KEY (PERSONNE_COMMUNE_ID_NAISSANCE) 
PREFERENCES COMMUNE ( COMMUNE_ID) , 

constraint communedecesf k FOREIGN KEY ( PERSONNE_COMMUNE_I D_DECES ) 
PREFERENCES COMMUNE ( COMMUNE_ID) , 

constraint communeinhumationf k FOREIGN KEY ( PERSONNE_C0MMUNE_I D_I NHUMATION) 
PREFERENCES COMMUNE ( COMMUNE_ID) 

-- constraint perefk FOREIGN KEY (PERSONNE_PERE_ID) REFERENCES PERSONNEC PERSONNE_I D) , 
-- constraint merefk FOREIGN KEY (PERSONNE_MERE_ID) REFERENCES PERSONNEC PERSONNE_I D) , 
-- constraint parrainfk FOREIGN KEY (PERSONNE_PARRAIN_ID) REFERENCES 
*PERSONNE(PERSONNE_ID), 

-- constraint marrainefk FOREIGN KEY (PERSONNE_MARRAINE_ID) REFERENCES 
^PERSONNE(PERS0NNE_ID) 
); 

-- Table : MARIAGE 

create table MARIAGE 
( 
MARIAGE_MARI_ID INTEGER not null, 
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MARIAGE_FEMME_ID INTEGER not null. 

MARIAGE_TEM0IN1_ID INTEGER null, 

MARIAGE_TEM0IN2_ID INTEGER null, 

MARIAGE_TEM0IN3_ID INTEGER null, 

MARIAGE_TEM0IN4_ID INTEGER null, 

MARIAGE_DATE_CIVIL DATE null, 

MARIAGE_DATE_CIVIL_APP CHAROO) null, 

MARIAGE_COMMUNE_ID_CIVIL INTEGER null, 

MARIAGE_DATE_RELIGIEUX DATE null, 

MARIAGE_DATE_RELIGIEUX_APP CHAROO) null, 

MARIAGE_PAROISSE_ID_RELIGIEUX INTEGER null, 

MARIAGE_CIVIL INTEGER null, 

MARIAGE_RELIGIEUX INTEGER null, 

constraint PK_MARIAGE primary key (MARIAGE_MARI_I D.MARIAGE_FEMME_I D ) , 

constraint mariagemarif k FOREIGN KEY (MARIAGE_MARI_ID) 
PREFERENCES PERSONNE(PERSONNE_ID) , 

constraint mariagefemmefk FOREIGN KEY (MARIAGE_FEMME„ID) 
PREFERENCES PERSONNE(PERSONNE_ID) , 

constraint mariagetemoinlf k FOREIGN KEY (MARIAGE_TEMOI N1_ID) 
PREFERENCES PERSONNE(PERSONNE_ID) , 

constraint mariagetemoin2f k FOREIGN KEY (MARIAGE_TEM0IN2_ID) 
PREFERENCES PERSONNE(PERSONNE_ID) , 

constraint mariagetemoin3f k FOREIGN KEY (MARIAGE_TEM0IN3_ID) 
PREFERENCES PERSONNE(PERSONNE_ID) , 

constraint mariagetemoin4f k FOREIGN KEY (MARIAGE_TEM0IN4_ID) 
PREFERENCES PERSONNE(PERSONNE_ID) , 

constraint mariagecommunefk FOREIGN KEY (MARIAGE_COMMUNE_ID_CI VI L) 
PREFERENCES COMMUNE(COMMUNE_ID) , 

constraint mariageparoissefk FOREIGN KEY (MARIAGE_PAROISSE_ID_RELIGIEUX) 
PREFERENCES COMMUNE(COMMUNE_ID) 
); 

-- Table : TYPE_ACTE 

create table TYPE_ACTE 
( 

TYPE_ACTE_ID INTEGER not null, 

TYPE_ACTE_NOM VARCHAR(255) not null, 

constraint PK_TYPE_ACTE primary key (TYPE_ACTE_ID) 
); 

-- Table : ACTE 



create table ACTE 
( 

ACTE_ID INTEGER not null, 

ACTE_LIBELLE VARCHARC255) not null, 

ACTE_TYPE_ID INTEGER not null, 

ACTE_DATE DATE not null , 
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ACTE_LIEU_ID INTEGER not null, 
ACTE_SOURCE VARCHAR null, 
ACTE_AUTEUR VARCHAR null, 
ACTE_TEXTE VARCHAR null , 
ACTE_MARGE_TEXTE VARCHAR null, 
ACTE_URL_IMAGE varchar(255) null, 
constraint PK_ACTE primary key (ACTE_ID), 

constraint actetypefk FOREIGN KEY ( ACTE_TYPE„ID) REFERENCES TYPE_ACTE(TYPE_ACTE_ID) , 
constraint actel ieuidfk FOREIGN KEY ( ACTE_LI EU_ID) REFERENCES COMMUNE(COMMUNE_ID) 
); 

-- Table : LIAISON_ACTE 

create table LIAISON_ACTE 
( 

PERSONNE_ID INTEGER not null, 

ACTE_ID INTEGER not null, 

constraint PK_LIAISON_ACTE primary key (PERSONNE_ID,ACTE_ID) , 

constraint 1 iaisonactepersonnef k FOREIGN KEY (PERSONNE_ID) 
PREFERENCES PERSONNE(PERSONNE_ID) , 

constraint 1 iaisonacteactef k FOREIGN KEY (ACTE_ID) REFERENCES ACTE(ACTE_ID) 
); 

-- Table : TYPE_DOCUMENT 

create table TYPE_DOCUMENT 
( 

TYPE_DOCUMENT_ID INTEGER not null, 

TYPE_DOCUMENT_NOM VARCHAR(255) not null, 

constraint PK_TYPE_DOCUMENT primary key (TYPE_DOCUMENT_ID) 
); 

-- Table : DOCUMENT 

create table DOCUMENT 
( 

DOCUMENTED INTEGER not null, 

DOCUMENT_LIBELLE VARCHAR(255) not null, 

DOCUMENT_TYPE_ID INTEGER not null, 

DOCUMENT_URL_IMAGE VARCHAR(255) null, 

DOCUMENT_SOURCE VARCHAR(255) null, 

DOCUMENT_DATE VARCHAR(255) null, 

DOCUMENT_TRANSCRIPTION INTEGER null, 

DOCUMENT_MARGE_COMMENTAIRES VARCHAR null, 

DOCUMENT_COMMENTAIRES VARCHAR null, 

constraint PK_DOCUMENT primary key (DOCUMENTED) , 

constraint documenttypef k FOREIGN KEY (DOCUMENT_TYPE_ID) 
PREFERENCES TYPE_DOCUMENT(TYPE_DOCUMENT_ID) 
); 
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Table : LIAISONJDOCUMENT 



create table LIAISON_DOCUMENT 
( 

PERSONNE_ID INTEGER not null, 

DOCUMENT_ID INTEGER not null, 

constraint PK_LIAISON_DOCUMENT primary key (PERSONNE_ID, DOCUMENTED) , 

constraint 1 iaisonphotopersonnefk FOREIGN KEY (PERSONNE_ID) 

PREFERENCES PERSONNE(PERSONNE_ID) , 

constraint 1 iaisonphotophotof k FOREIGN KEY (DOCUMENTED) 

PREFERENCES DOCUMENT; DOCUMENT_ID) 
); 



Table : LIAISON_DOCUMENTS 



create table LIAISON_DOCUMENTS 
( 

D0CUMENT1_ID INTEGER not null, 

D0CUMENT2_ID INTEGER not null, 

constraint PK_LIAIS0N_D0CUMENTS primary key (DOCUMENT1_ID,DOCUMENT2_ID) 

constraint 1 iaisondocumentlfk FOREIGN KEY (D0CUMENT1_ID) 

PREFERENCES D0CUMENT(DOCUMENT_ID) , 

constraint 1 iaisondocument2fk FOREIGN KEY (D0CUMENT2_ID) 

PREFERENCES D0CUMENT(DOCUMENT_ID) 
); 



Table : LIAISON_ACTES 



create table LIAISON_ACTES 

( 

ACTE1_ID INTEGER not null , 
ACTE2_ID INTEGER not null , 

constraint PK_LIAISON_ACTES primary key (ACTE1_ID,ACTE2_ID) , 
constraint 1 iaisonactelfk FOREIGN KEY (ACTE1_ID) REFERENCES ACTE(ACTE_ID) , 
constraint 1 iaisonacte2fk FOREIGN KEY (ACTE2_ID) REFERENCES ACTE(ACTE_ID) 

); 



Table : LIAISON_ACTE_DOCUMENT 



create table LIAISON_ACTE_DOCUMENT 

( 

ACTE_ID INTEGER not null, 
DOCUMENT_ID INTEGER not null, 

constraint PK_LIAISON_ACTE_DOCUMENT primary key (ACTE_ID, DOCUMENTED) , 
constraint 1 iaisonactef k FOREIGN KEY (ACTE_ID) REFERENCES ACTE(ACTE_ID) 
constraint 1 iaisondocumentfk FOREIGN KEY (DOCUMENTED) 
PREFERENCES D0CUMENT( DOCUMENTED) 

); 
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Table : PAGE_SUPPLEMENTAIRE 



create table PAGE_SUPPLEMENTAIRE 
( 

PERSONNE_ID INTEGER not null, 

CLASSE_NOM VARCHAR(255) not null, 

PAGEJRDRE INTEGER not null , 

constraint PK_PAGE_SUPPLEMENTAIRE primary key ( PERSONNE_I D , CLASSE_NOM) 
); 



Table : TABLES 



create table TABLES 
( 

TABLES_ID INTEGER not null , 

TABLES_COMMUNE_ID INTEGER not null, 

TABLES_DATE_ACTE DATE not null, 

TABLES_NOM VARCHAR(255) not null, 

TABLES_PRENOM VARCHAR(255) not null, 

TABLES_ID_PERE INTEGER null, 

TABLES_NOM_PERE VARCHARC255) null, 

TABLES_PRENOM_PERE VARCHAR(255) null, 

TABLES_ID_MERE INTEGER null, 

TABLES_NOM_MERE VARCHARC255) null, 

TABLES_PRENOM_MERE VARCHAR(255) null, 

TABLES_ID_DEPENDANCE INTEGER null, 

TABLES_D0UBL0N INTEGER null, 

TABLES_TYPE_ACTE_ID INTEGER not null, 

TABLES_PERSONNE_ID INTEGER null, 

TABLES_PERSONNE_HOMME INTEGER null, 

TABLES_PERSONNE_AGE INTEGER null, 

TABLES_PERSONNE_PERE_AGE INTEGER null, 

TABLES_PERSONNE_MERE_AGE INTEGER null, 

TABLES_PERSONNE_ORIGINE VARCHAR(255) null, 

constraint PK_TABLES primary key (TABLES_ID), 

constraint actetypefk FOREIGN KEY (TABLES_TYPE_ACTE_ID) 
PREFERENCES TYPE_ACTE(TYPE_ACTE_ID) , 

constraint actepersonnef k FOREIGN KEY (TABLES_PERSONNE_ID) 
PREFERENCES PERSONNE(PERSONNE_ID) 
); 



Table : FAMILLE 



create table FAMILLE 

( 
FAMILLE_ID INTEGER not null , 
FAMILLE_NOM VARCHAR(255) not null, 
constraint PK_TABLES primary key (FAMILLE_ID) 

); 
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Table : LI AI SON_FAMI LLE 



create table LIAISON_FAMI LLE 
( 

PERSONNE_ID INTEGER not null, 

FAMILLE_ID INTEGER not null, 

constraint PK_LIAIS0N_PH0T0 primary key ( PERSONNE_I D , FAMI LLE_I D ) , 

constraint 1 iaisonphotopersonnefk FOREIGN KEY (PERSONNE_ID) 

PREFERENCES PERSONNE(PERSONNE_ID) , 

constraint 1 iaisonphotophotof k FOREIGN KEY ( FAMI LLE_ID) 

PREFERENCES FAMI LLE( FAMI LLE_ID ) 
); 



Table : RECHERCHE_ADR 



create table RECHERCHE_ADR 
( 

RECHERCHE_ADR_ID INTEGER not null, 

RECHERCHE_ADR_LIBELLE VARCHAR(255) not null, 

RECHERCHE_ADR_DESCRIPTIF VARCHAR(255) not null, 

RECHERCHE_ADR_COMMUNE_ID INTEGER not null, 

constraint PK_RECHERCHE_ADR primary key (RECHERCHE_ADR_ID) , 

constraint rechercheadrcommunefk FOREIGN KEY (RECHERCHE_ADR_COMMUNE_ID) 

PREFERENCES COMMUNE(COMMUNE_ID) 
); 



Table : RECHERCHE_WADR_REPERTOI RE 



create table RECHERCHE_WADR_REPERTOIRE 
( 

RECHERCHE_WADR_REPERTOIRE_ID INTEGER not null, 

RECHERCHE_WAOR_REPERTOIRE_NOM VARCHARC255) not null, 

constraint PK_RECHERCHE_WADR_REPERTOIRE primary key (RECHERCHE_WADR_REPERTOIRE_ID) 
); 



Table : RECHERCHE_WEB_ADR 



create table RECHERCHE_WEB_ADR 
( 

RECHERCHE_WEB_ADR_ID INTEGER not null, 

RECHERCHE_WEB_ADR_LIBELLE VARCHARC255) not null, 

RECHERCHE_WEB_ADR_DESCRIPTIF VARCHAR(255) not null, 

RECHERCHE_WADR_REPERTOIRE_ID INTEGER not null, 

constraint PK_RECHERCHE_WEB_ADR primary key (RECHERCHE_WEB_ADR_ID) , 

constraint rechercheadrcommunefk FOREIGN KEY (RECHERCHE_WADR_REPERTOIRE_ID) 

PREFERENCES RECHERCHE_WADR_REPERTOIRE( RECHERCHE_WADR_REPERTOI RE_ID) 
); 
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Table : LIAISON_RECHERCHE_ADR 



create table LIAISON_RECHERCHE_ADR 
( 

RECHERCHE_ADR_ID INTEGER not null, 

RECHERCHE_WEB_ADR_ID INTEGER not null, 

constraint PK_LIAISON_RECHERCHE_WEB_PERS0NNE primary key 

*(RECHERCHE_ADR_ID,RECHERCHE_WEB_ADR_ID), 

constraint 1 iaisonrechercheadrf k FOREIGN KEY (RECHERCHE_ADR_ID) 

PREFERENCES RECHERCHE_ADR( RECHERCHE_ADR_ID) , 

constraint 1 iaisonrecherchewebadrf k FOREIGN KEY (RECHERCHE_WEB_ADR_ID) 

PREFERENCES RECHERCHE_WEB_ADRCRECHERCHE_WEB_ADR_ID) 
); 



Table : TYPE_RECHERCHE 



create table TYPE_RECHERCHE 
( 

TYPE_RECHERCHE_ID INTEGER not null, 

TYPE_RECHERCHE_NOM VARCHAR(255) not null, 

TYPE_RECHERCHE_WEB VARCHAR(255) not null, 

constraint PK_TYPE_RECHERCHE primary key (TYPE_RECHERCHE_ID) 
); 



Table : ETAT_RECHERCHE 



create table ETAT_RECHERCHE 
( 

ETAT_RECHERCHE_ID INTEGER not null, 

ETAT_RECHERCHE_NOM VARCHAR(255) not null, 

ETAT_RECHERCHE_COULEUR BIGINT not null, 

constraint PK_ETAT_RECHERCHE primary key (ETAT_RECHERCHE_ID) 
); 



Table : RECHERCHE 



create table RECHERCHE 

( 

RECHERCHE_ID INTEGER not null, 
RECHERCHE_NOM VARCHAR(255) not null, 
RECHERCHE_PERIODE VARCHAR(255) not null, 
RECHERCHE_DESCRIPTIF VARCHAR null, 
RECHERCHE_DESCRIPTIF_RETOUR VARCHAR nul" 
RECHERCHE_DATE_DEMANDE DATE not null, 
RECHERCHE_DATE_RETOUR DATE null, 
RECHERCHE_ETAT_ID INTEGER not null, 
RECHERCHE_TYPE_ID INTEGER not null, 
RECHERCHE_COMMUNE_ID INTEGER not null, 
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RECHERCHE_ADR_ID INTEGER not null, 

constraint PK_RECHERCHE primary key (RECHERCHE_ID) , 

constraint etatrecherchefk FOREIGN KEY (RECHERCHE_ETAT_ID) 

PREFERENCES ETAT_RECHERCHE(ETAT_RECHERCHE_ID) , 

constraint typerecherchef k FOREIGN KEY (RECHERCHE_TYPE_ID) 

PREFERENCES TYPE_RECHERCHE(TYPE_RECHERCHE_ID) , 

constraint communerecherchefk FOREIGN KEY (RECHERCHE_COMMUNE_ID) 

PREFERENCES COMMUNE(COMMUNE_ID) , 

constraint adrrecherchefk FOREIGN KEY (RECHERCHE_ADR_ID) 

PREFERENCES RECHERCHE_ADR(RECHERCHE_ADR_ID) 



); 



Table : RECHERCHE_WEB 



create table RECHERCHE_WEB 
( 

RECHERCHE_WEB_ID INTEGER not null, 

RECHERCHE_WEB_NOM VARCHAR(255) not null, 

RECHERCHE_WEB_PERIODE VARCHAR(255) not null, 

RECHERCHE_WEB_DESCRIPTIF VARCHAR null, 

RECHERCHE_WEB_DESCRIPTIF_RETOUR VARCHAR null, 

RECHERCHE_WEB_DATE_DEMANDE DATE not null, 

RECHERCHE_WEB_DATE_RETOUR DATE null, 

RECHERCHE_WEB_ETAT_ID INTEGER not null, 

RECHERCHE_WEB_TYPE_ID INTEGER not null, 

RECHERCHE_WEB_COMMUNE_ID INTEGER not null, 

RECHERCHE_WEB_ADR_WEB_ID INTEGER not null, 

constraint PK_RECHERCHE primary key (RECHERCHE_WEB_ID) , 

constraint etatrecherchewebfk FOREIGN KEY (RECHERCHE_WEB_ETAT_ID) 

PREFERENCES ETAT_RECHERCHE(ETAT_RECHERCHE_ID) , 

constraint typerecherchewebfk FOREIGN KEY (RECHERCHE_WEB_TYPE_ID) 

PREFERENCES TYPE_RECHERCHE(TYPE_RECHERCHE_ID) , 

constraint communerecherchewebfk FOREIGN KEY (RECHERCHE_WEB_COMMUNE_ID) 

PREFERENCES COMMUNE(COMMUNE_ID) , 

constraint adrrecherchewebfk FOREIGN KEY (RECHERCHE_WEB_ADR_WEB_ID) 

PREFERENCES RECHERCHE_WEB_ADR(RECHERCHE_WEB_ADR_ID) 
); 



Table : LIAIS0N_RECHERCHE_PERSONNE 



create table LIAISON_RECHERCHE_PERSONNE 
( 

PERSONNE_ID INTEGER not null, 

RECHERCHE_ID INTEGER not null, 

constraint PK_LIAISON_RECHERCHE_PERSONNE primary key (PERSONNE_ID,RECHERCHE_ID) 

constraint 1 iaisonpersonnefk FOREIGN KEY (PERSONNE_ID) 

PREFERENCES PERSONNE(PERSONNE_ID) , 

constraint 1 iaisonrecherchefk FOREIGN KEY (RECHERCHE_ID) 

PREFERENCES RECHERCHEC RECHERCHE_ID) 
); 
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Table : LIAISON_RECHERCHE_WEB_PERSONNE 



create table LIAISON_RECHERCHE_WEB_PERSONNE 
( 

PERSONNE_ID INTEGER not null, 

RECHERCHE_WEB_ID INTEGER not null, 

constraint PK_LIAISON_RECHERCHE_WEB_PERSONNE primary key 

*(PERSONNE_ID,RECHERCHE_WEB_ID), 

constraint 1 iaisonpersonnelfk FOREIGN KEY (PERSONNE_ID) 

PREFERENCES PERSONNE(PERS0NNE_ID) , 

constraint 1 iaisonrecherchewebf k FOREIGN KEY (RECHERCHE_WEB_ID) 

PREFERENCES RECHERCHE_WEB(RECHERCHE_WEB_ID) 
); 



Table : ACCES 



create table ACCES 
( 

ACCES_ID INTEGER not null, 

ACCES_LOGIN VARCHAR(255) not null, 

ACCES_PASSWORD VARCHAR(255) not null, 

ACCES_ACTIVE INTEGER null, 

ACCES_TOTAL INTEGER null, 

ACCES_BORNE_SUP INTEGER null, 

constraint PK_ACCES primary key (ACCES_ID) 
); 



Table : ACCES_FAMI LLE 



create table ACCES_FAMI LLE 

( 

ACCES_ID INTEGER not null, 
FAMILLE_ID INTEGER not null , 

constraint PK_ACCES_FAMI LLE primary key (ACCES_ID,FAMILLE_ID) , 
constraint 1 iaisonaccesfk FOREIGN KEY (ACCES_ID) REFERENCES ACCES(ACCES_ID) , 
constraint 1 iaisonfamil lef k FOREIGN KEY (FAMILLE_ID) REFERENCES FAMI LLE ( FAMI LLE_I D) 

); 



Table : ACCES_TYPE_DOCUMENT 



create table ACCES_TYPE_DOCUMENT 

( 

ACCES_ID INTEGER not null, 
TYPE_DOCUMENT_ID INTEGER not null, 

constraint PK_ACCES_TYPE_DOCUMENT primary key (ACCES_ID,TYPE_DOCUMENT_ID) , 
constraint 1 iaisonaccesfk FOREIGN KEY (ACCES_ID) REFERENCES ACCES(ACCES_ID) 
constraint 1 iaisonfamil lef k FOREIGN KEY (TYPE_DOCUMENT_ID) 
PREFERENCES TYPE_DOCUMENT(TYPE_DOCUMENT_ID) 

); 
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Table : ACCES_PAYS 



create table ACCES_PAYS 
( 

ACCES_ID INTEGER not null, 

PAYS_ID INTEGER not null, 

constraint PK_ACCES_PAYS primary key (ACCES_ID,PAYS_ID) , 

constraint 1 iaisonaccesfk FOREIGN KEY (ACCES_ID) REFERENCES ACCES(ACCES_ID) , 

constraint 1 iaisonpaysf k FOREIGN KEY (PAYS_ID) REFERENCES PAYS(PAYS_ID) 
); 



Table : ACCES_DEPARTEMENT 



create table ACCES_DEPARTEMENT 

( 

ACCES_ID INTEGER not null, 
DEPARTEMENT_ID INTEGER not null, 

constraint PK_ACCES_DEPARTEMENT primary key (ACCES_ID,DEPARTEMENT_ID) , 
constraint 1 iaisonaccesfk FOREIGN KEY (ACCES_ID) REFERENCES ACCES(ACCES_ID) , 
constraint 1 iaisondepartementf k FOREIGN KEY ( DEPARTEMENT_ID) 
PREFERENCES DEPARTEMENT(DEPARTEMENT_ID) 

); 



Table : ACCES_COMMUNE 



create table ACCES_COMMUNE 
( 

ACCES_ID INTEGER not null , 
COMMUNE_ID INTEGER not null, 
constraint PK_ACCES_COMMUNE primary key (ACCES_ID,COMMUNE_ID) , 

liaisonaccesfk FOREIGN KEY (ACCES_ID) REFERENCES ACCES(ACCES_ID) , 
liaisoncommunefk FOREIGN KEY (COMMUNE_ID) REFERENCES COMMUNE(COMMUNE_ID) 



constraint 
constraint 
); 
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Refactoring 

des applications 

Java/JSEE 



Ameliorer la qua lite et I'evolutivite des applications Java/J2EE 

Le refactoring consiste a refondre le code source d'une application existante ou en cours de develop- 
pement pour en ameliorer la qualite, avec pour objectif une reduction des couts de maintenance et 
une meilleure evolutivite. 

L'ouvrage passe en revue les differentes techniques de refactoring utilisees en environnement 
Java/J2EE : extraction de methodes, generalisation de type, introduction de design patterns, pro- 
grammation orientee aspect, optimisation de I'acces aux donnees, etc. 

Un livre pratique illustre d'une etude de cas detaillee 

L'ouvrage decrit dans le detail le processus de refactoring d'une application Java/J2EE : mise en place 
de I'infrastructure et des outils, analyse de la conception et du code de I'application, mise en ceuvre 
des techniques de refonte, tests de non regression. 

Cette demarche est illustree par une etude de cas complete : refactoring d'une application J2EE Open 
Source a I'aide d'outils tels que Eclipse, CVS, JUnit et PMD. 



Au sommaire 

Cycle de vie des applications et refactoring. Le processus de refactoring. Mise en place de I'infra- 
structure de gestion de configuration et de test • Analyse de I'application [mesures quantitatives 
et revues qualitatives) et determination du perimetre de refactoring • Techniques de refactoring : 
renommage, extraction de methodes, generalisation de type, deplacements d'elements, etc. • 
Tests unitaires avec JUnit, simulacres d'objets avec EasyMock, analyse de couverture avec EMMA. 
Techniques avancees de refactoring. Introduction de design patterns [Cbservateur, Etat, 
Interpreteur, Strategie, Proxy, Fagade, Adaptateur) • Programmation orientee aspect • 
Optimisation de I'acces aux donnees : refactoring de la structure de la base, des requetes SQL, 
des developpements JDBC. Etude de cas detaillee. Presentation de I'application et mise en place 
de I'infrastructure de refactoring • Analyse quantitative et qualitative de I'application • Mise en 
ceuvre des techniques de refactoring et tests de non-regression. 
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